1. Requirements
Reference: Software Engineering, by Ian Sommerville, 6th edition, Chapters 5, 6, & 8

2. Objectives To introduce and contrast user and system requirements
To explain functional and non-functional requirements
To present guidelines for writing system requirements
To introduce the concept of use cases for describing functional requirements
CMSC 345, Spring 2003

3. Requirements Engineering
The process of establishing
the services that are required of the system, and
the constraints under which it operates and is developed
The requirements themselves are the descriptions of both of these items.
CMSC 345, Spring 2003

4. Who’s Who?
Client – the person(s) paying for the development and will become the owner of the product
Customer – the person who will buy the product off the shelf (mass marketing), or who has the final say as to whether the product is acceptable (in-house development). May be the same as the client
Stakeholder – anyone who should have some direct or indirect influence on the system requirements
Reference: Mastering the Requirements Process, Robertson and Robertson
CMSC 345, Spring 2003

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
CMSC 345, Spring 2003

6. Requirements Readers
CMSC 345, Spring 2003

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.
CMSC 345, Spring 2003

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.
CMSC 345, Spring 2003

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.
CMSC 345, Spring 2003

10. Requirements Imprecision
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.
CMSC 345, Spring 2003

11. Requirements Completeness and Consistency
In principle, requirements should be both complete and consistent.
Complete
They should include descriptions of all required functionality
Consistent
There should be no conflicts or contradictions in the descriptions of the system functions
In practice, it is impossible to produce a complete and consistent requirements document.
CMSC 345, Spring 2003

12. 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.
CMSC 345, Spring 2003

13. 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.
CMSC 345, Spring 2003

14. 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.
CMSC 345, Spring 2003

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.
CMSC 345, Spring 2003

16. NFRs Must Be Verifiable, Too!
Non-verifiable
The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized.
Verifiable
Experienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.
CMSC 345, Spring 2003

17. Some Requirements Measures
CMSC 345, Spring 2003

18. Writing Requirements
Requirements may be written using a natural language (common for user requirements)
Lack of clarity, possibly ambiguous
Requirements confusion
Functional and non-functional requirements tend to be mixed-up
Requirements amalgamation
Several different requirements may be expressed together
Tables and diagrams may help
CMSC 345, Spring 2003

19. Example: Editor Grid Requirement
2.6 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.
CMSC 345, Spring 2003

20. 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)
CMSC 345, Spring 2003

21. Alternatives to NL Specification
CMSC 345, Spring 2003

22. Some Guidelines for Writing Requirements
Invent or find a standard format and use it for all requirements.
Use language in a consistent way.
Use “shall” or “will” for mandatory requirements, “should” for desirable requirements.
Use text highlighting (e.g., italics) to identify key parts of the requirement.
Do not use vague phrases (e.g., “around a month,” “have basic knowledge of”)
Every requirement must be verifiable.
Every requirement should be numbered for traceability.
CMSC 345, Spring 2003

23. Use Cases A way of describing a system’s functional requirements
Describes the system’s behavior under various conditions as the system responds to a request from one of the stakeholders called the primary actor.
The primary actor initiates some interaction with the system to accomplish some goal.
The system responds, protecting the interests of all of the stakeholders.
Different sequences of behaviors (scenarios) can unfold, depending on the request and the conditions surrounding the request. The use case gathers these scenarios together.
CMSC 345, Spring 2003