The document discusses requirements engineering for software development. It defines requirements engineering, outlines the requirements engineering process, and describes key requirements documents like the software requirements specification. It also covers topics like requirements attributes, validation, management, and traceability.

1. Requirements Engineering SW

2. Requirements Engineering Definitions, Requirements Engineering Process Requirements Document for customers/developers IEEE Recommended Practice for Software Requirements Overview Std. 830 SRS Software Requirements Specifications Functional Specification Document for developers

3. Definition Q&A

4. Definition Requirements Engineering Finding out Checking Documenting the services and constraints of a software application

5. Requirements Engineering Process Requirements analysis Feasibility report Requirements validation Requirements document Feasibility study Requirements specification System models user and system requirements realism consistency completeness new software product/service

6. Requirements Analysis Requirements sorting Application context understanding Requirements prioritization Requirements collection Requirements grouping Requirements Document

7. Attributes Q&A

8. Attributes Maintainability May evolve for changing user requirements Dependability Reusable, secure, safe Efficiency Use of resources (CPU, memory) Usability Used by a group of users (UI) Adaptability Portability - configurations, OS

9. Requirements Document 1. Introduction - need for the software program, context, brief functionality . 2. Hardware -special hardware, minimal, optimal configurations. 3. Conceptual model - high level view of the software program 4. Functional Requirements -services provided to the user 5. Database Requirements -logical organization of the data 6. NonFunctional Requirements -other functionality that the software program should have (speed, size, ease of use, reliability,robustness, portability) 7. Maintenance/evolution -anticipated changes due to hardware evolution, changing user needs 8. Glossary -technical terms used 9. Index

10. Writing style Describe one external behavior (functionality) of the software application. Active rather than passive tenses. Short sentences. Reference number and description Itemized facts wherever possible Diagrams for complex descriptions Precise and well defined terms Short paragraphs Headings and Sub-headings Grammatically correct constructs and spell check

11. SRS Software Requirements Specifications IEEE Std. 830 Recommended Practice for Software Requirements Specifications SRS: Avoid placing design or project requirements. Avoid describing design or implementation details. Address the software product not the process of software development. Multiple SRSs: separate interface specs docs for interfaces among packages (communication interfaces, sw interfaces, db interfaces)

12. SRS References

13. IEEE Std. 830 SRS Characteristics Correct - all requirements will be met by the software product. Unambiguous - every requirements stated has one implementation. Complete - it includes: All significant requirements: Functional; performance; design constraints; attributes; external interfaces. Responses to all classes of input data Full labels, references to all figures/tables; glossary . Consistent - internally consistent. Ranked for importance/stability - identifier for every particular requirement. Verifiable - finite cost-effective process to check a particular requirement. Modifiable - changes made easily, completely and consistently while retaining the structure and state. Traceable - requirements are clear.

14. Prototype SRS Outline Table of Contents 1. Introduction Purpose - purpose and audience for SRS. Scope - for the sw: name, usage, benefits, goals . Definitions and abbreviations References Overview 2. Overall Description Product Perspective Product Features User Characteristics Constraints Assumptions and dependencies

15. Prototype SRS Outline 3. Specific Requirements 3.1 Functional Requirements processing and outputs of the software for certain inputs, specifications provided for validating inputs; sequencing outputs, error response. 3.1.1 Functional Requirement 1 3.1.1.1 Introduction 3.1.1.2 Inputs 3.1.1.3 Processing 3.1.1.4 Outputs 3.1.2 Functional Requirement 2 3.1.2.1 Introduction 3.1.2.2 Inputs 3.1.2.3 Processing 3.1.2.4 Outputs …

16. Prototype SRS Outline 3.2 External Interfaces Requirements 3.2.1 User Interfaces 3.2.2 Hardware Interfaces 3.2.3 Software Interfaces 3.2.3 Communications Interfaces … 3.3 Performance Requirements Static: # of terminals, # of users, connections supported, amount of data stored/processed. Dynamic: maximum allowed response time for processing events. 3.4 Design Constraints 3.4.1 Standard Compliance Standards or regulations of the application domain with which the software must comply 3.4.2 Hardware Limitations …

17. Prototype SRS Outline 3.5 Software System Attributes 3.5.1 Reliability 3.5.2 Availability 3.5.3 Security 3.5.4 Maintainability 3.5.5 Portability 3.6 Other Requirements 3.6.1 Data Base 3.6.2 Operations 3.6.3 … 4. Appendixes 5. Glossary 6. Index

18. Requirements Validation The requirements actually define the system which the customer wants. Validity checks Requirements define one feature of the application Consistency checks Requirements shouldn’t conflict Completeness checks The requirements define all the functions of the software application Realism checks The software application can actually be implemented Verifiability checks The delivered application meets the requirements

19. Requirement Validation Techniques Requirements Reviews Requirements are analyzed systematically by the QA. Software Prototyping User experiments with a model of a software application Test Case Generation if test cases may be generated Automated Consistency Analysis CASE Tools

20. Requirement Management Requirements review of the requirement document Formal Verifiability - testable Comprehensibility – requirements properly understood? Tractability – origin of the requirements Adaptability Informal Definition – requirements management Process of understanding and controlling changes to requirements Managing requirements change

21. Type of Requirements Enduring requirements Relatively stable, core attributes of a software application Volatile requirements Environment: policies, OS versions Mutable –environment of the organization Emergent – emerge with the customer understanding Consequential – another computer system - changes in an org processes Compatibility – depends on a particular computer system or a business process

22. Requirement Management Planning Requirements identification Identify the requirement so it can be referenced A change management process Asses the impacts and costs of the changes Tractability policy Relationships Among requirements Requirements and design CASE Tool Support Requirements storage Change management Traceability info management

23. Traceability info management 1. Source traceability info Stakeholders Rationale for requests Module Module Module 2. Requirements traceability info 3. Design traceability info Dependent links Stakeholders consulted Requirement text …. Requirement text …. Requirement text ….

24. Requirements Management Tools