REQUIREMENTS ANALYSIS CONCEPTS PRINCIPLES Requirement IEEE defines Software

REQUIREMENTS ANALYSIS CONCEPTS & PRINCIPLES

Requirement IEEE defines Software Requirements as: A condition or capability needed by user to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. A documented representation of a condition or capability as in 1 or 2.

User requests Problem Analysis A relatively good understanding of user’s requirements System Description Software Requirements Specification

Importance of Requirements Fred Brooks in “The Mythical Man Month” states “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the system if done wrong. No other part is more difficult to rectify later. ”

Requirements Analysis and Definition q. The requirements analysis and definition establish the system's services, constraints and goals by consultation with users. q. They are then defined in a manner that is understandable by both users and development staff. q. This phase can be divided into: q. Requirements analysis q. Requirements definition q. Requirements specification q. Requirements define the function of the system from the client's viewpoint.

Requirements in Software Development Feasibility and Planning Requirements All process models include a requirements activity Design Implementation Operation and Maintenance

Goals during the requirements phase Understand the requirements in detail (analysis). Describe the requirements in a manner that is clear to the client. Ensure that the client understands the description of the requirements and their implications. Describe the requirements in a manner that is clear to the people who will design and implement the system. The Requirements Documentation is the defining document that describes the goals of the system that is being built. It may form a legal contract between client and software developers.

The requirements process Feasibility Study Requirements Analysis Requirements Model Feasibility Report Work with the client to understand the requirements Requirements Analysis (optional) Requirements Specification Organize the requirements in a systematic and comprehensible manner Documentation of Requirements

Role of Software Requirements Construction Process User Documentation Project Planning Software Requirements System Testing Project Tracking Change Control

Risks of Inadequate Requirements Inappropriate user involvement leads to unacceptable products Creeping user requirements degrade the quality Ambiguous requirements leads to rework and reeffort The operator identity consists of the operator name and password; the password consists of six digits. It should be displayed on the security VDU and deposited in the login file when an operator logs into the system. Gold plating adds unnecessary requirements Minimal Specifications lead to missing requirements, impossible tracking

Levels of Requirements Business Requirements User Requirements Tasks which a user become able to accomplish Requirement definition Functional Requirements (derived from user Req) State high level business objective Main system features Vision or scope System View and system perspective Developers must build into product Non Functional requirements Services along Constraints Quality and Performance attributes

Example – Word Processing – Spell Checker Business Requirement User will be able to correct spelling errors in a document efficiently User Requirement (user perspective) finding spelling errors in the document and decide whether to replace each misspelled word with the one chosen from a list of suggested words Functional requirement find and highlight misspelled words then display suggested replacements. The user will be allowed to select from the list of suggested replacements. Upon selection it will replace the misspelled word with the selected word. It will also allow the user to make global replacement Non Functional Requirement must be integrated into the existing word-processor

Requirements analysis 1. Identify the stakeholders: q Who is affected by this system? q Client q Senior management q Production staff q Computing staff q Customers q etc. ,

Requirements analysis 2. Understand the requirements in depth: • Domain understanding • Understanding of the real requirements of all stakeholders

Requirements analysis 3. Organize the requirements: • Classification into coherent clusters • Recognize and resolve conflicts

Requirement Statement and Requirement Specification document Requirement Statement Requirement Definition Record User Requirements Requirement Specification Document Functional Specification Record Functional requirements

Requirement Statement Characteristics Complete - requirement must fully describe the functionality to be delivered Correct - Each requirement must accurately describe the functionality to be built Feasible - must be possible to implement each requirement Necessary -requirement should document something that is required for conformance Prioritized - An implementation priority must be assigned. Unambiguous - consistent interpretation. Verifiable – User should be able to devise a small number of tests to determine whether the requirement was properly implemented

Requirement Specification Characteristics Complete Consistent Modifiable Traceable

Relationship between components of Software Requirements

Realism and verifiability Requirements must be realistic, i. e. , it must be possible to meet them. Wrong: The system must be capable of x (if no known computer system can do x at a reasonable cost). Requirements must be verifiable, i. e. , it must be possible to test whether a requirement has been met. Wrong: The system must be easy to use. Right: After one day's training an operator should be able to input 50 orders per hour.

New and old systems In requirements analysis it is important to distinguish: • • features of the current system proposed new features Clients often confuse the current system with the underlying requirement. A new system is when there is no existing system. A replacement system (or subsystem) is when a system is built to replace an existing system. A legacy system is an existing system that is not being replaced, but must interface to the new system.

Requirements analysis: negotiation with the client q Sometimes the client will request some functionality that is very expensive or impossible. What do you do? q Talk through the requirement with the client. Why is it wanted? Is there an alternative that is equivalent? q Explain the reasoning behind your concern. Explain the technical, organizational, and cost implications. q Be open to suggestions. Is there a gap in your understanding? Perhaps a second opinion might show other approaches q Before the requirements phase is completed the client and development team must resolve these questions.

Requirement Elicitation Fact Gathering Techniques Interviews Questionnaires Analyzing documents Observation . . .

Requirements Analysis and Specification Many projects fail: because they start implementing the system: without determining whether they are building what the customer really wants.

Unspoken requirements Examples: • Resistance to change • Departmental friction • Management strengths and weaknesses Discovering the unspoken requirements is often the most difficult part of developing the requirements.

Business Requirements Vision Statement Assumption and Dependencies Scope Context Diagram

Requirement Document Use Cases High Level Expanded Diagram Activity Diagrams Non Functional Requirements

Verifying Requirements Source and Sink Analysis analyst determines all the sources of requirements and where do these requirements consume (sinks) E. g Report: source of this report is the data (and who enters it) that is input to be retrieved later in the form of the report. whoever needs this report become the sink of the report. software engineer who is involved in validating such requirements, should identify all the sources against sinks or vice versa to determine complete end-to-end requirements

Credits Material taken and Modified from Roger S. Pressman 6 th Edition, Chapter 7 Barry Bohem and A. Egyed, Software Requirements Negotiation, Some lessons learned Proc Intl Conference Software Engineering ACM/IEEE 1998 pp 503 -506 Lecture Slides of Dr. Fakhar Lodhi, VU CS 504