REQUIREMENT ENGINEERING

CUONG V. NGUYEN - SE 2020 1

AGENDA
▪ Requirement engineering
▪ Functional vs non-functional requirements
▪ Domain requirements
▪ Common issues
▪ Agile view of requirements

CUONG V. NGUYEN - SE 2020 2

REQUIREMENTS ENGINEERING
▪ The process of defining, documenting, and maintaining requirements in the
engineering design process.
▪ The requirements themselves are the descriptions of the system services and
constraints that are identified during the requirements engineering process.

CUONG V. NGUYEN - SE 2020 3

WHAT IS A REQUIREMENT
▪ A requirement can be high-level abstract statement to a detailed
mathematical expression.
▪ Requirement may be used for:
 A bid for contract: more abstraction, open to interpretation
 The actual contract for signing: this time it should be as detail as possible

▪ It is often challenging:

CUONG V. NGUYEN - SE 2020 4

REQUIREMENT EXAMPLE
▪ Abstract statement: “The system shall generate monthly reports in pdf”
▪ User story: “As a [persona], I [want to], [so that].”
▪ Example: “As an user, I want to see the list of products available for me, so
that I can start selecting them if interested.”
▪ Diagram:

CUONG V. NGUYEN - SE 2020 5

ACTORS
▪ Users: This group comprises those who will operate the software
▪ Customers: This group comprises those who have commissioned the software or who
represent the software’s target market.
▪ Market/Business analysts: A mass-market product will not have a commissioning
customer, so marketing people are often needed to establish what the market
needs and to act as proxy customers.
▪ Regulators: Many application domains, such as banking and public transport, are
regulated. Software in these domains must comply with the requirements of the
regulatory authorities
▪ Software engineers: Implement the requirements into product. These individuals
have a legitimate interest in profiting from developing the software by, for
example, reusing components in or from other products. Best case is requirements fit
well with the skill set of the engineers.

CUONG V. NGUYEN - SE 2020 6

ACTIVITIES
▪ Requirements inception: Developers and stakeholders meet
▪ Requirements analysis and negotiation: Requirements are identified both
written and graphical tools. Examples: use cases and user stories.
▪ Requirements specification: Requirements are documented in a formal
artifact called a Requirements Specification
▪ Requirements validation: Checking that the documented requirements and
models are consistent and meet the needs of the stakeholder.
▪ Requirements management: Managing all the activities related to the
requirements since inception, supervising as the system is developed and,
even until after it is put into use (e. g., changes, extensions, etc.)

CUONG V. NGUYEN - SE 2020 7

TYPES OF REQUIREMENTS
▪ User requirements
 Statements in understandable language or pictures and diagram
 Targeted for customers.

▪ System requirements
 A structured document setting out detailed descriptions of the system’s functions, services and
operational constraints.
 Defines what should be achieved and implemented, what technical aspects are required
 Can be used as supplement for a real contract

CUONG V. NGUYEN - SE 2020 8

FUNCTIONAL AND NON-FUNCTIONAL
▪ Functional requirements:
▪ How the system should react to particular inputs and how the system should behave
in particular situations.
▪ Can also be what the system should not do. Ex: “Should not allow client to buy
product before registration”
▪ Non-functional requirements:
▪ Constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards. Ex: “The system
should use a NoSQL engine as the main database solution”
▪ Often apply to the system as a whole rather than individual features or services
▪ Domain requirements

CUONG V. NGUYEN - SE 2020 9

PROBLEMS WITH REQUIREMENT
▪ Often, following are things to avoid:
▪ Requirements are not precisely stated
▪ Requirements does not specify the systems affected
▪ Requirements not complete: edge case scenario
▪ Ambiguous requirements
▪ No validation conditions
▪ Conflicting with other descriptions
▪ Reality: always the case, communications is the solution.
CUONG V. NGUYEN - SE 2020 10
PROBLEMS WITH REQUIREMENT

CUONG V. NGUYEN - SE 2020 11

DOMAIN REQUIREMENT ISSUES
▪ Not easy to understand
▪ Often expressed in the language of the particular domain
▪ Hard to be understood by software engineers
▪ Domain business analysts often are specialists in the area, they do not think
of making the domain requirements explicit
▪ Example: Applications written for investment banking, need to express
clearly terms of fixed income, equities, options, future, price currency.
▪ Solution often requires extensive communications/education.

CUONG V. NGUYEN - SE 2020 12

NON-FUNCTIONAL REQUIREMENT METRICS
▪ Time ▪ Reliability
 Transactions / sec  Mean time to failure
 Response time  Downtime probability
 Time to complete an operation  Failure rate
 Availability
▪ Space
 Main memory ▪ Robustness
 Auxiliary memory  Time to recovery
 (Cache)  % of incidents leading to catastrophic failures
 Data corruption probability after a failure
▪ Usability
 Training time ▪ Portability
 Number of choices  % of non-portable code
 Mouse clicks  Number of systems where software can run

CUONG V. NGUYEN - SE 2020 13

SOFTWARE REQUIREMENTS SPECIFICATION
▪ Typical structure: ▪ 3. External Interface Requirements
 3.1 User interfaces
▪ 1. Introduction  3.2 Hardware interfaces
 1.1 Purpose
 3.3 Software interfaces
 1.2 Document conventions
 3.4 Communication protocols and interfaces
 1.3 Intended audience
 1.4 Product Scope ▪ 4. System Features
 4.1 System feature A
▪ 2. Overall Description  4.1.1 Description and priority
 2.1 Product perspective  4.1.2 Action/result
 2.2 Product functions  4.1.3 Functional requirements
 2.3 User classes and characteristics  4.2 System feature B
 2.4 Operating environment
 2.5 User environment
 2.6 Design/implementation constraints
 2.7 Assumptions and dependencies

CUONG V. NGUYEN - SE 2020 14

SOFTWARE REQUIREMENTS SPECIFICATION
▪ 5. Other Nonfunctional ▪ Appendix A:
Requirements Terminology/Glossary/Definitions
 5.1 Performance requirements
▪ Appendix B: Analysis Models
 5.2 Safety requirements
 5.3 Security requirements ▪ Revision History
 5.4 Software quality attributes

▪ 6. Other Requirements

CUONG V. NGUYEN - SE 2020 15

SOME GUIDELINES
▪ Use a standard format and use it for all requirements.
▪ Use language in a consistent way. It is a common practice to use
 shall for mandatory requirements
 should for desirable requirements.
▪ Use text highlighting to identify key parts of the requirement.
▪ Avoid the “etc.”.
▪ Avoid Noise: useless or irrelevant piece of information
▪ Avoid Ambiguity: phrases with several interpretations
▪ If some uncertainty remains, use acronyms such as TBD (To Be Defined)
▪ Include an explanation (rationale) of why a requirement is necessary.

CUONG V. NGUYEN - SE 2020 16

CHARACTERISTICS OF A GOOD SRS
▪ a) Correct;
▪ b) Unambiguous;
▪ c) Complete;
▪ d) Consistent;
▪ e) Ranked for importance and/or stability;
▪ f) Verifiable;
▪ g) Modifiable;
▪ h) Traceable. *IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830

CUONG V. NGUYEN - SE 2020 17

VIEW FROM AGILE PERSPECTIVE
▪ Agile methods don’t focus on producing a complete requirements document
as requirements change so quickly.
▪ The document is therefore always considered out of date, and are subject to
change.
▪ A middle ground agreement often results in incremental requirements
engineering and express requirements as ‘user stories’.
▪ This is practical for business systems but problematic for systems that require
a lot of pre-delivery analysis (e.g. critical systems) or systems developed by
several teams.

CUONG V. NGUYEN - SE 2020 18

SUMMARY
▪ Requirements for a software system set out what the system should do and
define constraints on its operation and implementation.
▪ Functional requirements: specification of the functionalities that the system
must provide or how some computations must be carried out.
▪ Non-functional requirements : constrain the system being developed and the
process being used.
▪ A well defined requirement specification is crucial, because it is the ground
on which implementation, validation, contract, and budget are based on.

CUONG V. NGUYEN - SE 2020 19