1. Requirements Analysis
CS 560
Lecture 5

2. Software Process Step: Requirements
Requirements define the function of the system from the client’s viewpoint.
They establish functionality, constraints, and goals
They may be developed in a self-contained study, or may emerge incrementally.
They form the basis for acceptance testing.
Developers and client need to work closely during the requirements phase(s).
Requirements must be developed in a manner that is understandable by both the client and the development staff.

3. Types of Requirements User requirements System requirements
Statements in natural language plus diagrams of the services the system provides and its operational constraints.
Written for customers.
System requirements
A structured document giving detailed descriptions:
System functions (HW/SW)
Services
Operational constraints
Defines what should be implemented client.

4. User and System Requirements

5. User and System Requirements

6. Why are requirements important?
Causes of failed software projects:
Incomplete requirements: %
Lack of user involvement: %
Lack of resources: %
Unrealistic expectations: 9.9%
Lack of executive support: 9.3%
Changing requirements and specs: 8.8%
Lack of planning: %
System no longer needed: 7.5%
Failures to understand the requirements can lead the development team to build the wrong system.

7. Requirement Goals Understand the requirements in appropriate detail.
Define the requirements in a manner that is clear to the client.
Written specifications
Prototype(s) of components/integrated systems
Other forms of communication
Define the requirements that’s clear to developers who will design, implement, and maintain the system.
CS 560 groups should use the second milestone presentation and the accompanying report to confirm the requirements with the client.
"Our understanding of your requirements is that ...”

8. Requirements completeness and consistency
Requirements should be both complete (as much as possible) and consistent
Completeness:
Include descriptions of all facilities required for the project.
Consistent:
No conflicts or contradictions in the descriptions of the project requirements.
In practice, it is very difficult to produce a complete and consistent requirements document.

9. Steps in the requirements phase (documentation)
The requirements part of a project can be divided into several stages, and broken down into sub-stages later:
Analysis – to establish the system’s services, constraints, and goals by consulting with clients, customers, and users.
Modeling – Organizing the requirements in a systematic and comprehensible manner.
Defining, recording, and communicating the requirements.
With agile methods, these stages will be repeated several times.

10. Requirement analysis: client interviews
Client interviews are the heart of the requirements analysis.
Clients may have only a vague concept of requirements.
Prepare before you meet with the client.
Keep full notes.
If you do not understand, ask the client to explain again.
Repeat what you hear.
For your CS 560 projects you will have several scheduled meetings with your client to analyze the requirements.

11. Requirement analysis: Understanding the requirements
Understand the requirements in depth
Domain understanding
Example: Manufacturing light bulbs
Understanding the requirements of all stakeholders
Stakeholders may not have clear ideas about what they require, or they may not express requirements clearly.
Understanding the terminology
Clients often use specialized terminology. If you do not understand it, ask for an explanation.
Keep asking questions, “Why do you do things this way?” “Is this essential?” “What are the alternatives?”

12. Requirement analysis: Unspoken Requirements
Discovering the unspoken requirements is often the most difficult part of developing the requirements.
Examples:
Requirements that the client thinks are obvious
Modeling/Design confusion based on low detail requirement
Requirements unknown to the client
Any assumption(s) made during RE, modeling/design, and implementation MUST be validated by the client.
Iterative process of requirements analysis

13. Requirement analysis: Stakeholders (Documentation)
Who is affected by the system?
Client
Senior management
Production staff
Computing staff
Customers
Users (many categories)
Example:
E-commerce website (shoppers, administration, finance, warehouse)

14. Defining and communicating requirements
Objectives
Record agreement between clients and developers
Provide a basis for acceptance testing
Provide visibility
Be a foundation for program and system design
Communicate with other teams who may work on or rely on this system
Inform future maintainers
Can be done by developing a complete Software Requirements Specification document.

15. Defining and communicating requirements: Realism and verifiability
Requirements must be realistic, i.e., it must be possible to meet them.
The system must be capable of x (if no known computer system can do x at a reasonable cost).
Wrong
Requirements must be verifiable, since the requirements are the basis for acceptance testing
It must be possible to test whether a requirement has been met.
The system must be easy to use.
After one day's training an operator should be able to input 40 orders per hour.
Correct

16. Functional requirements
Services the system should provide
How the system should react to particular inputs
How the system should behave
They are identified by analyzing the system and include topics such as:
Data
User interfaces
Technical details
Problems arise when functional requirements are not precisely stated.

17. Non-Functional requirements
Requirements that are not directly related to the functions that the system must perform
Product requirements
performance, reliability, portability, etc...
Process requirements
Specific programming languages, IDE, etc...
Organizational requirements
delivery, training, standards, etc...
External requirements
legal, interoperability, etc...
Marketing and public relations

18. Metrics for specifying nonfunctional requirements

19. Requirements: negotiation with the client
Some requests from the client may conflict with others.
Recognize and resolve conflicts
Functionality vs. cost vs. timeliness
Example:
Operating System fast boot: quick boot vs. recognize all equipment on bus

20. The software requirements document (Documentation)
The software requirements document is the official statement of what is required of the system developers.
Should include:
Definitions of user requirements.
Detailed specifications of the system requirements.
As far as possible, it should set of WHAT the system should do rather than HOW it should do it.

21. The structure of a requirements document
Chapter
Description
Introduction
Defines the expected readership of the document, purpose, and project scope.
General Description
Describes general factors that affect the project. (High-level functions, user characteristics, assumptions, dependencies, etc.)
Specific Reqs. User/System, etc.
Provides details for all specific requirements (functional, non-functional, user, hardware, etc.) related to the project.
Analysis Models
Describes specific requirements using the Unified Modeling Language, UML. Each model should be traceable to a requirement(s). (Sequence, Class, User, State, Data flow pipeline, etc.)
System Hardware Architecture
Provides a description of the system hardware, showing the distribution of functions across different system modules.

22. Guidelines for writing requirements
Invent a standard format and use it for all requirements.
Use text highlighting to identify key parts of the requirement.
Avoid the use of jargon.
Include an explanation (rationale) of why a requirement is necessary.

23. Requirements engineering processes
The processes used for RE vary widely depending on the application domain, the people involved and the organization developing the requirements.
There are a number of generic activities common to all processes:
Requirements gathering
Requirements analysis
Requirements validation
Requirements management
In practice, RE is an iterative activity in which these processes are performed multiple times.

24. Process activities Requirements discovery
Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.
Requirements classification and organization
Group related requirements and organize them into coherent clusters.
Prioritization and negotiation
Prioritizing requirements and resolving requirements conflicts.
Requirements specification
Requirements should be documented for the current iteration of the software project.

25. Key points
The software requirements document is an agreed statement of the system requirements and user requirements.
It should be organized so that both system customers and software developers can use it.
The requirements engineering process is an iterative process including:
Requirements gathering
Specification
Validation
Requirements gathering and analysis is an iterative process that may be repeated:
Requirements discovery
Requirements classification and organization
Requirements negotiation
Requirements documentation

26. Key points
Each CS 560 project group should be gathering project documentation specifications from:
Lecture slides
Associated book chapters
Supplemental reading