Requirements Analysis

Transcription

1 Requirements Analysis Quiz with Explainations Hans-Petter Halvorsen, M.Sc.

2 Questions 1. What is Software Requirements? 2. Requirements vs. Design What is the main difference(s)? 3. List different types of Requirements 4. What is User Requirements? 5. What is System Requirements? 6. What is Functional Requirements? 7. What is Non-Functional Requirements? 8. Give some Examples of Non-Functional Requirements 9. What is SRS? 10. Mention some Requirements Analysis Problems/Challenges?

3 What is Software Requirements?

4 STD System Documentation Testing Software Test Documentation Test Plan Test Documentation End-User Documentation Implementation Code System Documentation User Guides Deployment Maintenance Design Installation Guides The Software Development Lifecycle (SDLC) SDD Planning SDP Software Development Plan Project Planning Gantt Chart Requirements Analysis SRS Software Requirements Specifications Gantt Chart Software Design Documents with ER Diagram, UML Diagrams, CAD Drawings

5 Software Requirements Requirements for a software system set out what the system should do and define constraints on its operation and implementation 5

6 Requirements: The statements that describe what the software system should be but not how it is to be constructed. Requirements Engineering: A set of activities related to the development and agreement of the final set of requirement specifications. Steps in the Requirements Engineering Process:

7 Why spend time on Requirements Analysis? Cost per defects and changes Software Development Life Cycle (SDLC) 7

8 Take the Requirements Analysis seriously!! 8

9 Requirements vs. Design What is the main difference(s)?

10 Software Requirements & Design Requirements (WHAT): WHAT the system should do Describe what the system should do with Words and Figures,etc. SRS Software Requirements Specification Software Design (HOW): HOW it should do it Examples: GUI Design, UML, ER diagram, CAD, etc. SDD Software Design Document Many dont separate SRS and SDD documents, but include everything in a Requirements document. In practice, requirements and design are inseparable. 10

11 3. List different types of Requirements

12 Software Requirements High-Level Requirements Detailed Requirements. Typical written by the Customers, Project Management, etc. Typical written by Software Architects, Software Developers, etc.

13 High-Level Requirements WHAT should the system do? Who should use the system What is the purpose with the system? Performance What parts should the system consists of What Platforms should be used (PC, Tablet, Web?,...) etc. Use Words and Figures in order to describe these Requirements 13

14 Software Requirements Categories Requirements User Requirements System Requirements Functional Requirements Non-Functional Requirements 14

15 What is User Requirements?

16 User Requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. I. Sommerville, Software Engineering: Pearson,

17 What is System Requirements?

18 System Requirements A structured document setting out detailed descriptions of the system s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor. I. Sommerville, Software Engineering: Pearson, 2010.

19 User vs. System Requirements Examples: User requirement definition 1. The MHC-PMS shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month. System requirements specification 1.1 On the last working day of each month, a summary of the drugs prescribed, their cost and the prescribing clinics shall be generated. 1.2 The system shall automatically generate the report for printing after on the last working day of the month. 1.3 A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed and the total cost of the prescribed drugs. 1.4 If drugs are available in different dose units (e.g. 10mg, 20 mg, etc.) separate reports shall be created for each dose unit. 1.5 Access to all cost reports shall be restricted to authorized users listed on a management access control list. I. Sommerville, Software Engineering: Pearson,

20 User vs. System Requirements Examples: User requirement definition 1. The MHC-PMS shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month. System requirements specification 1.1 On the last working day of each month, a summary of the drugs prescribed, their cost and the prescribing clinics shall be generated. 1.2 The system shall automatically generate the report for printing after on the last working day of the month. 1.3 A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed and the total cost of the prescribed drugs. 1.4 If drugs are available in different dose units (e.g. 10mg, 20 mg, etc.) separate reports shall be created for each dose unit. 1.5 Access to all cost reports shall be restricted to authorized users listed on a management access control list. I. Sommerville, Software Engineering: Pearson,

21 What is Functional Requirements?

22 Functional Requirements Describe functionality or system services. Depend on the type of software, expected users and the type of system where the software is used. Functional user requirements may be high-level statements of what the system should do. Functional system requirements should describe the system services in detail. I. Sommerville, Software Engineering: Pearson,

23 What is Non-Functional Requirements?

24 Non-Functional Requirements These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular IDE, programming language or development method. Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless. I. Sommerville, Software Engineering: Pearson,

25 Give some Examples of Non- Functional Requirements

26 Non-Functional Requirements Examples Product Requirement: The systemshall be available to all clinics during normal working hours (Mon Fri, ). Downtime within normal working hours shall not exceed five seconds in any one day. Organizational Requirement: Users of the system shall authenticate themselves using their health authority identity card. External requirement: The system shall implement patient privacy provisions as set out in HStan priv.

27 What is SRS?

28 The Software Requirements Document Software Requirements Specifications (SRS) The software requirements document is the official statement of what is required of the system developers. Should include both a definition of user requirements and a specification of the system requirements. It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it. I. Sommerville, Software Engineering: Pearson,

29 The Structure of the SRS Document Example 1 Chapter Preface Description This should define the ex pec ted readership of the document and describe its version history, including a rationale for the creation of a new version and a summary of the changes made in each version. Introduction This should describe the need for the system. It should briefly describe the system s functions and ex pl ai n how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of theorganizationcommissioning the software. Glossary This should define the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader. User requirements definition Here, you describe the services provided for the user. The nonfunctional system requirements should also be described in this section. This description may use natural language, diagrams, or other notations that are understandable to customers. Product and process standards that must be followed should be specified. System architecture This chapter should present a high-level overview of the anticipated system architecture, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted. System requirements specification This should describe the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements. Interfaces to other systems may be defined. System models This might include graphical system models showing the relationships between the system components and the system and its environment. Examples of possible models are object models, data-flow models, or semantic data models. System evolution This should describe the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on. This section is useful for system designers as it may hel p them avoid design decisions that would constrain likely future changes to the system. Appendices These should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions. Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data. Index I. Sommerville, Software Engineering: Pearson, Several indexes to the document may be included. As well as a normal al phabeti c index, there may be an index of diagrams, an index of functions, and so on. 29

30 The Structure of the SRS Document Example 2 A. System Overview (brief description of what the softare system will do) B. Technical Requirements (Functional requirement, Nonfunctional requirements, User-interface specification, User task flow, Input/output and other data specifications, Interface specifications to other systems) C. Acceptance Criteria/Interaction Scenarios D. Validation/Verification E. Requirements Considerations (Assumption made about the software, End users, Existing systems, Environment, Limitations) F. Other Information... Essentials of Software Engineering, Frank Tsui; Orlando Karam; Barbara Bernal, 3 ed., Jones & Bartlett Learning

31 Mention some Requirements Analysis Problems/Challenges?

32 Problems/Challenges O. Widder. (2013). geek&poke. Available: Stakeholders don t know what they really want. Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements. Organisational and political factors may influence the system requirements. The requirements change during the analysis process. New stakeholders may emerge and the business environment may change. I. Sommerville, Software Engineering: Pearson, 2010.

33 References Software Development - A Practical Approach Halvorsen, Hans-Petter, 2015 Essentials of Software Engineering Frank Tsui; Orlando Karam; Barbara Bernal, 3 ed., Jones & Bartlett Learning Software Engineering I. Sommerville, 10 ed.: Pearson, 2015 Software Engineering. Modern Approaches E. J. Braude and M. E.Bernstein, 2 ed.: Wiley,

34

35 Hans-Petter Halvorsen, M.Sc. University College of Southeast Norway Blog: