1. Requirements Engineering
Chapter 3
Requirements Analysis, Negotiation and Modeling
Part 1
Dr. Eman Al-Maghary

2. Characteristics of good requirements
Valid (or “correct”)
Expresses only the real needs of the stakeholders (customers, users,…)
Complete
Specifies all the things the system must do and all the things it must not do!
Conceptual Completeness
E.g. responses to all classes of input
Structural Completeness
E.g. no TBDs!!!
Necessary
Doesn’t contain anything that isn’t “required”

3. Characteristics of good requirements (Cont.)
Consistent
Doesn’t contradict itself (i.e. is satisfiable)
Uses all terms consistently
Note: inconsistency can be hard to detect especially in timing aspects and business logic
Unambiguous
Every statement can be read in exactly one way
Clearly defines confusing terms
E.g. in a glossary
Understandable (Clear)
E.g. by non-computer specialists
Technical notations should only be used as backup (e.g. in an appendix)

4. Characteristics of good requirements (Cont.)
Verifiable
A process exists to test satisfaction of each requirement
“every requirement is specified behaviorally”
Modifiable
Can be changed without difficulty
Good structure and cross -referencing
It must be kept up to date!
Feasible, Prioritized, Traceable, Precise… …

5. Types of Requirements User requirements System requirements
Should describe requirements so that they are understandable by those who do not have detailed technical knowledge. Written mainly for customers (end users)
System requirements
A structured document setting out detailed descriptions of the system services and constraints. Written as a contract between client and contractor
Software design specification
An abstract description of the software design that can serve as a basis for a more detailed design. Bridges the gap between requirements and design. Written for developers

6. Requirements Readers

7. Functional and Non-functional Requirements
Statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations
Non-functional requirements
Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

8. Functional Requirements
Describe functionality or system services
These services depend on
the type of software being developed
the expected users of the software
Functional user requirements may be high-level statements of what the system should do, but functional system requirements should describe the system services in detail.

9. Functional Requirement Examples
The user shall be able to add or delete problems to/from the problem collection.
The user shall be able to preview an examination on the monitor.
A student shall be able to take an examination on-line.
The system will automatically grade an examination upon completion by the student.

10. Requirements Ambiguity
Problems arise when requirements are not precisely stated.
Ambiguous requirements may be interpreted in different ways by developers and clients.
Requirements should also be verifiable.
Examples:
The user shall be able to modify the problem collection.
The user shall be able to use an existing exam.

11. Non-functional Requirements
Define system properties and constraints
Examples:
response time
storage requirements
process requirements (e.g., must use a particular CASE system, programming language, or development method)
Non-functional requirements may be more critical than functional requirements. If one is not met, the system may be useless.

12. Non-functional Requirements Examples
Product requirements
- An examination shall accommodate true/false, multiple choice, and short answer questions.
An exam question and the space for its answer must not be divided between two printed pages.
- The system must run under Red Hat Linux, Version 6.2.
- The system must be written in C++, compilable using Microsoft Visual C++, Version 6.0.

13. More Non-functional Requirements
User interface requirements
The user interface shall be text-based.
The user interface shall be menu-driven.
The UMBC logo shall always be displayed in the upper right-hand corner of the screen.

14. ISO 9126 Quality Characteristics & Sub-characteristics
1. Functionality
1.1 Suitability
1.2 Accuracy
1.3 Interoperability
1.4 Security
2. Reliability
2.1 Maturity
2.2 Fault Tolerance
2.3 Recoverability
3. Usability
3.1 Understandability
3.2 Learnability
3.3 Operability
3.4 Attractiveness
4. Efficiency
4.1 Time Behavior
4.2 Resource Utilization
5. Maintainability
5.1 Analyzability
5.2 Changeability
5.3 Stability
5.4 Testability
6. Portability
6.1 Adaptability
6.2 Installability
6.3 Co-existence
6.4 Replaceability

15. More Non-functional Requirements
Organizational requirements
The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95.
External requirements
The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.

16. Some Requirements Measures

17. Example: Editor Grid Requirement
Grid facilities To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, via an option on the control panel. Initially, the grid is off. The grid may be turned on and off at any time during an editing session and can be toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of grid lines shown will be reduced to avoid filling the smaller diagram with grid lines.

18. Problems! Difficult to read Mixes three different requirements:
Functional requirement (the need for a grid)
Non-functional requirement (grid units)
Non-functional UI requirement (grid switching)

19. Exercise
(1) We need a software system to manage information about our products: create descriptions, delete, edit and so on. (2) I think it can be done with Oracle and those Java packages for accessing it. (3) Anyway, the system should be created with Java, (4) because we want it to be portable. (5) And the system will need to send an to all our registered customers, when a new product is added. (6) We want to increase our exposure to potential buyers, you know. (7) And this is a reason also why we need that system operational already a month before Christmas. (8) Yeah, of course all those junk-mail regulations must be taken into account. (9) The system should be quite easy-to-use, because our sales department people are not computer experts.. (10) And yeah, only people from the sales department are allowed to add, delete or edit products, others can only see the information. (11) What else.. Part of data will come from our Helsinki office, they use some XML-based format, so the system will need to understand that format, (12) and load the data automatically into the database.

20. Solution 1 – User requirement.
2 – Technological Constraint (optional).
3 – Design Constraint.
4 – Quality Attribute (portability).
5 – Functional requirement.
6 – Business requirement.
7 – Project requirement (schedule).
8 – Business rule.
9 – Quality Attribute (usability).
10 – Business rule.
11 – External Interface requirement.
12 – Functional requirement.

21. Alternatives to NL Specification
Structured Natural Language
This approach depends on defining forms or templates to express the RS.
Design Description Languages
This approach uses a language like a programming language but with more abstract features to specify the requirements by defining an operational model of the system.

22. Alternatives to NL Specification (Cont.)
Graphical Notations
A graphical language, supplemented by text annotations is used to define the functional requirements for the system. For example: (SADT in 1977 and Use-case descriptions in 1993)
Mathematical Specifications
These notations based on mathematical concepts such as finite-state machines or sets