SE262 - Requirements Engineering

• SE262 Software Engineering Chapter 3 focuses on requirements engineering.

Requirements Engineering Part I

• Requirements engineering is the process of defining, documenting, and maintaining requirements in the software development lifecycle.
• The topics covered include an overview of requirements engineering, functional and non-functional requirements, and the Software Requirements Specification (SRS).

Ariane 5 Flight 501

• In June 1996, the Ariane 5 rocket exploded shortly after launch due to a software error.
• The error was an unhandled numeric exception (integer overflow).
• This event is a case study for illustrating issues with requirements specification, critical systems validation, and software reuse problems.
• The development cost was nearly $8 billion, with a $500 million satellite payload lost.

National Cancer Institute, Panama City

• In November 2000, a U.S. firm, Multidata Systems International, provided software for radiation therapy.
• The software led to a miscalculation of radiation dosage.
• Eight patients died, and 20 received overdose radiation.
• The physicians responsible for checking the calculations were indicted for murder.

What are Requirements?

• Requirements are descriptions of system services and constraints generated during the requirements engineering process.

Software Development Process & Requirement Engineering Process

• The stages involved in software development are - Feasibility Study, Requirement Elicitation and analysis, Requirements Specification, Requirements Validation, User and System Requirements, Agreed SRS and Requirements Document.

Why Focus on Requirements?

• Defects in requirements account for 56% of issues.
• Defects in code account for 7% of issues.
• Other defects account for 10% of issues.
• Defects in design account for 27% of issues.
• Effort to fix defects in requirements represents 82%.
• Effort to fix defects in code represents 1%.
• Other efforts account for 4%.
• Design efforts account for 13%.

Requirements

• Functional requirements specify what the system should do.
• Non-functional requirements specify how the system should behave (performance, reliability, etc.).
• Domain requirements are constraints from the system's operational domain.

Functional Requirements Examples

• A user can search appointment lists for all clinics.
• The system generates a daily list of patients expected to attend appointments for each clinic.
• Each staff member is uniquely identified by an 8-digit employee number.
• The system identifies positive or negative sentiments behind emojis.
• The Human Resource System checks the qualifications of individuals for a job position.

Issues writing Functional requirements

• Ambiguity refers to requirements that can be interpreted in different way be developers and users.
• In principle, requirements should be complete and consistent.
• 'Complete' means they should include description of all facilities required.

Glossary Technique for addressing ambiguities

• A glossary is a collection of technical terms relevant in particular project or domain.
• It enables all the stakeholders to have the same understanding.

Non-Functional Requirements

• A quality requirement concerns how the system behaves (performance, reliability, etc.).
• Non-functional requirements often apply to the system as a whole.
• These requirements can be more critical than functional requirements; failure to meet them may render the system useless.

Software Product Quality

• Functional Suitability: Appropriateness, accuracy, compliance.
• Reliability: Availability, fault tolerance, recoverability, compliance.
• Performance Efficiency: Time behavior, resource utilization, compliance.
• Operability: Appropriateness, recognizability, learnability, ease of use, attractiveness, accessibility, compliance.
• Security: Confidentiality, integrity, non-repudiation, accountability, authenticity, compliance.
• Compatibility: Co-existence, interoperability, compliance.
• Maintainability: Modularity, reusability, analyzability, changeability, stability, testability, compliance.
• Transferability: Adaptability, installability, replaceability, portability, compliance.

Example of Quality Requirements

• Performance: Website load time must not exceed 1 second.
• Reliability: Applicants can access their resume 98% of the time without failure.

Non-functional requirements implementation

• Single non-functional requirement may generate a number of related functional requirements and may also generate requiremnts that restrict existing requirements.

Software Requirements Specification (SRS)

• SRS is the central outcome of requirements engineering.
• SRS is the official statement of required information for system developers.
• It includes user and system requirements but is not a design document.
• It defines what the system should do, not how it should do it.

Requirement Analysis

• High-level requirements are decomposed into levels of details.

User requirement definition example

• MHC-PMS shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month.

System requirement specification definition example

• On the last working day of the month, a summary of the drugs prescribed, their cost and the prescribing clinics shall be generated.
• The system shall automatically generate the report for printing after 17.30 on the last working day of the month.
• A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed and the total cost of the prescribed drugs.
• If drugs are available in different dose units (e.g. 10mg, 20 mg, etc.) separate reports shall be created for each dose unit.
• Access to all cost reports shall be restricted to authorized users listed on a management access control list.

Requirements & Design

• Requirements should state what the system should do, and the design should describe how it does this.
• In practice, requirements and design are inseparable.

Appendix A Examples

• System prints vehicle reservation list at the end of the day (22:00-23:59 GMT+1).
• If a client has reserved the vehicle only temporarily, the vehicle rental system shall provide the client with the ability to cancel the reservation.
• Track facial movements.
• Suggest phrases to complete a conversation.
• Match couples for dating based on personal characteristics.
• Assess the qualification of job applicants.

Appendix B Examples

• Website's load time should not be more than 1 second.
• Applicants can access their resume 98% of the time without failure.
• Automated email services can be under maintenance for three hours.
• Recoverability: The system must be fully functional within three days of a major incident.
• Capacity: Support 500 applicants for resume review and store 1,000,000 resumes.
• Environmental: Resume reviews are performed Monday through Friday from 9 AM to 6 PM.
• Data integrity: Maintain data integrity by backing up all database updates.
• Usability

Requirements Engineering Part II

• Requirements engineering processes:
  • Requirements elicitation.
  • Requirements specification.
  • Requirements validation.

Requirements Elicitation

• Requirements Elicitation is discovering and gathering the problem to be solved rather than understanding the problems.
• It involves discovering and gathering information about application domain and services.
• Constraints limit solution space (e.g., budget, timeline, resources).
• Discovering the customer's real requirements is important to avoid dissatisfaction with the final system.

Requirements Elicitation Techniques

• Interview:

  • Closed Interview Examples: Yes/No, Agree/Disagree, Likert Scale.

  • Open Interview: Begin with Where?, Who?, Why?, When?, How?.

  • Tips:

  • Listen: Raise a question and listen attentively.

  • Ask in detail: "How exactly do you use the existing system?" "Why?".

  • Record response in your own words.

• Requirements Specification is the process of documenting requirements in a Software Requirements Specification (SRS).

• SRS should be part of a contract, complete, and accurate.

SRS structure assistance

• Providing the best practice based on industry experience.
• Facilitate completeness.

Document software requirements in SRS

• Use Natural language requirements (unstructured with a template).
• Use model-based requirements.

Structured NL Requirements

• Requirements template facilitate documenting structured individual requirements in natural language.
• The template can be used to avoid defects in specifying requirements.

Structured NL Requirements

• An autonomous system starts and executes functions independently where the user does not interact with it- Characteristic 1.
• The system provides the user with the ability to interact with the system - Characteristic 2.

Model-based Requirements

• UML Diagrams are used

Requirements engineering processes

• Requirements elicitation and analysis.
• Requirements specification.
• Requirements validation.

Requirements Validation

• Requirement validation is checking if the requirements meet stakeholder needs for the right system.

Requirements Validation Techniques

• Requirements reviews is undergoing formal (with completed documents) or informal reviews.
• Prototyping
  • Using clickable Graphical User Interface Design.

Elicitation Technique #2

• Questionnaire - Consist of multiple choice or open ended questions.
• Strengths - Learn from crowd, A lot of information with relative low cost.
• Weakness

Elicitation Technique #3

• Field observation - observe the users at work
• Strengths - Able to elicit requirements when stakeholders are busy or not good at describing their work.
• Weaknesses - Only elicit existing requirements (no new requirements).

Elicitation Technique #4

• Document Centric
• Strengths - Discover about old requirements, Detailed requirements are obtained.