Requirements Analysis CS 560 Lecture 5

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.

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.

User and System Requirements

User and System Requirements

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

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 ...”

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.

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.

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.

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?”

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

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)

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.

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

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.

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

Metrics for specifying nonfunctional requirements

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

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.

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.

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.

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.

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.

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

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