1. REQUIREMENTS ANALYSIS CONCEPTS & PRINCIPLES

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

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

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

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

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

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

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

9. SW Requirements Analysis definition of WHAT the software will do  A study of user needs for a problem to arrive at a definition of WHAT the software will do without describing how it will do it. Software Requirements Specification (SRS)  A Software Requirements Specification (SRS) is a document containing software requirements specification for a system.

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

11. Risks of Inadequate Requirements  Inappropriate user involvement leads to unacceptable products  Creeping user requirements degrade the quality  Ambiguous requirements leads to rework and re-effort  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

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

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

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

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

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

17. Requirement Statement and Requirement Specification document  Requirement Statement  Requirement Definition  Record User Requirements  Requirement Specification Document  Functional Specification  Record Functional requirements

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

19. Requirement Specification Characteristics  Complete  Consistent  Modifiable  Traceable

20. Relationship between components of Software Requirements

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

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

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

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

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

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

27. Anonymous infamous customer “ I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant”

28. Business Requirements  Vision Statement  Assumption and Dependencies  Scope  Context Diagram

29. Requirement Document  Use Cases  High Level  Expanded  Diagram  Activity Diagrams  Non Functional Requirements

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

31. 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 CS504