Software Requirement Analysis & Software Requirement Specification

1. Software Requirement Analysis & Software Requirement Specification Prepared By: ShresthaRoshan

2. Requirements Engineering Requirements engineering = gathering, negotiating, analyzing, and documenting requirements The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process.

4. What is Software Requirement?

5. Requirement: Introduction • "If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization's needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.“ -Davis

6. Requirement: Introduction • Requirements = services the system is expected to provide + constraints placed on the system • Software requirements are documentation that completely describes the behavior that is required of the software-before the software is designed built and tested. • The requirements could be expressed at various levels of abstraction. • The way requirements are defined has a major impact on the development of the software product.

7. Requirement Analysis & Specification Definition Requirements Specification • A document clearly and precisely describes each of the essential requirements of the software and the external interfaces(functions, performance, design constraint, and quality attributes). • Each requirement is defined in such a way that its achievement is capable of being objectively verified by a prescribed method; for example inspection, demonstration, analysis, or test. Requirements Analysis • The process of studying and analyzing the customer and the user/stakeholder needs to arrive at a definition of software requirements.

8. Requirements: Types A classification of requirements: User requirements: higher level description of services requested and constraints imposed System requirements: a more detailed, structured description of services and constraints. Usually included in the contract between the developer and the client An even more detailed description of requirements can be provided in a software design specification (closer to implementation)

9. Examples of user requirements definition and system requirements specification User Requirement Definition • The software must provide a means of representing and accessing external files created by other tools. • System requirements specification • 1.1The user should be provided with facilities to define the type of external files. • 1.2 Each external file type may have an associated tool which may be applied to the file. • 1.3 Each external file type may be represented as a specific icon on the user’s display. • 1.4 Facilities should be provided for the icon representing an external file type to be defined by the user. • 1.5 When a user selects an icon representing an external file, the effect of that selection is to apply the tool associated with the type of the external file represented by the selected icon.

10. User Requirements • Should be understood by the user, and should not address design and implementation aspects • Should focus on the key facilities required

11. System Requirements • More detailed specifications of user requirements • Included in the contract with the client • Used by developers as basis for design • May be specified using various models (object-oriented models, data-flow diagrams, formal specs, etc.) • Should indicate WHAT the system is required to do (not HOW) and under what conditions and constraints

12. System Requirements: Types • Functional requirements, describe the requested functionality/behaviour of the system: services (functions), reactions to inputs, exceptions, modes of operations. • Non-functional requirements, represent constraints on the system and its functionality: performance constraints, compliance with standards, constraints on the development process. • Domain requirements, can be either functional or non-functional and reflect the particularities of the application domain.

13. Non Functional Requirements: Types • Product requirements • Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. • Organisational requirements • Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc. • External requirements • Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

14. A Classification of Non-Functional Requirements Non-functional Requirements Product Requirements Organizational Requirements External Requirements Interoperability Requirements Efficiency Requirements Portability Requirements Delivery Requirements Ethical Requirements Implementation Requirements Usability Requirements Reliability Requirements Legislative Requirements Standards Requirements Performance Requirements Space Requirements Privacy Requirements Safety Requirements

15. What Vs How Dilemma User Requirements We learn what the user needs are. We propose how to address them by defining system requirements. We specify what we are going to build in system requirements. We describe how to address this by designing the system. The system design says what we are going to build. The software requirements tell how we will build part of the system in software. The software requirements tell what we will build in software. The software design how we are going to structure the software. The software design tells what software structure we will build. The code tells how this will be implemented. What How System Requirements What How System Design What How Software Requirements What How Software Design

16. “Walking on water and developing software from a specification are easy if both are frozen.”- Edward V. Berard

17. Requirement Analysts • Requirements analysts (or business analysts) build software requirements specifications through requirements elicitation. • Interviews with the users, stakeholders and anyone else whose perspective needs to be taken into account during the design, development and testing of the software • Observation of the users at work • Distribution of discussion summaries to verify the data gathered in interviews

18. Project background • Purpose of project • Scope of project • Other background information • Perspectives • Who will use the system? • Who can provide input about the system? • Project Objectives • Known business rules • System information and/or diagrams • Assumptions and dependencies • Design and implementation constraints • Risks • Known future enhancements • References • Open, unresolved or TBD issues Discussion Summary Outline

19. Software Requirement Specifications The software requirements specification (SRS) represents a complete description of the behavior of the software to be developed. The SRS includes: A set of use cases that describe all of the interactions that the users will have with the software. All of the functional requirements necessary to define the internal workings of the software: calculations, technical details, data manipulation and processing, and other specific functionality that shows how the use cases are to be satisfied Nonfunctional requirements, which impose constraints on the design or implementation (such as performance requirements, quality standards or design constraints).

20. Software Requirement Specification Document • SRS structure according IEEE/ANSI 830-1993 standard (overview only, many more details are given in the standard): • Introduction • General description • Specific requirements • Appendices • Index • This structure needs to be tailored for each particular organization

21. Example of a system requirement specified using structured natural language

22. Problem with Natural Language Lack of clarity Precision is difficult without making the document difficult to read. Requirements confusion Functional and non-functional requirements tend to be mixed-up. Requirements amalgamation Several different requirements may be expressed together.

23. Alternative to Natural Language • An alternative to natural language (NL) for software specification is Program Description Languages (PDL) • Derived from programming languages • May contain more abstract constructs • Their syntax and semantics could be checked • Recommended for describing sequences of actions whose order is important & for specifying software interfaces • However, PDL specification require advised readers, can be taken as design specs, and may not be expressive enough

24. Example of PDL requirements specification

25. Requirement Imprecision Problems arise when requirements are not precisely stated. Ambiguous requirements may be interpreted in different ways by developers and users. Consider the term ‘appropriate viewers’ User intention - special purpose viewer for each different document type; Developer interpretation - Provide a text viewer that shows the contents of the document.

26. Requirements Problems • Database requirements includes both conceptual and detailed information • Describes the concept of a financial accounting system that is to be included in LIBSYS; • However, it also includes the detail that managers can configure this system - this is unnecessary at this level. • Grid requirement mixes three different kinds of requirement • Conceptual functional requirement (the need for a grid); • Non-functional requirement (grid units); • Non-functional UI requirement (grid switching).

28. Requirement Completeness And Consistency In principle, requirements should be both complete and consistent. I. Complete They should include descriptions of all facilities required. II. Consistent There should be no conflicts or contradictions in the descriptions of the system facilities. In practice, it is impossible to produce a complete and consistent requirements document.

29. There is no perfect software, perfect system, perfect language or perfect code block that’s the whole reason “exceptions” were introduced and catching them made it into one of best practices.-Unknown

30. Key Points • Requirements set out what the system should do and define constraints on its operation and implementation. • Functional requirements set out services the system should provide. • Non-functional requirements constrain the system being developed or the development process. • User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams. • System requirements are intended to communicate the functions that the system should provide. • A software requirements document is an agreed statement of the system requirements. • The IEEE standard is a useful starting point for defining more detailed specific requirements standards.