1. SOFTWARE REQUIREMENT ANALYSIS AND SPECIFICATION

2. What is a requirement? It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. This is inevitable as requirements may serve a dual function May be the basis for a bid for a contract - therefore must be open to interpretation; May be the basis for the contract itself - therefore must be defined in detail; Both these statements may be called requirements.

3. CLASSIFICATION OF SOFTWARE REQUIREMENTS Functional requirements non-functional requirements User requirements System requirements

4. User and system requirements 4

5. FUNCTIONAL REQUIREMENTS Functional requirements Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. 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 but functional system requirements should describe the system services in detail.

6. EXAMPLES OF FUNCTIONAL REQUIREMENTS The user shall be able to search either all of the initial set of databases or select a subset from it. The system shall provide appropriate viewers for the user to read documents in the document store. Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.

7. Functional requirements specify what the product must do in order to satisfy the basic reason for its existence. Specifications of the product’s functionality. Actions the product must take – check, compute, record and retrieve. Derived from the basic purpose of the product. Normally business-oriented, rather than technical.

8. Non-functional requirements ( NFR ): constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless. Examples of NFR: includes of NFR include safety, security, usability, reliability and performance requirements. for instance, the user may want that product to be FAST, ACCURATE, USER FRIENDLY, ATTRACTIVE.

9. NON-FUNCTIONAL REQUIREMENT TYPES- 7M /8M / 15M

10. CLASSIFICATION OF NON- FUNCTIONAL REQUIREMENTS 10 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.

11. SOFTWARE REQUIREMENT SPECIFICATION DOCUMENT ( SRS )- complete description of the system’s behavior SRS is a perfect detailed description of the behavior of the system to be developed. SRS document is an agreement between the developer and the customer covering the functional and non functional requirements of the software to be developed. The basic issues that SRS must address : functionality external interfaces performance attributes design constraints imposed on an implementation.

12. Components of SRS : [ F2 SPED ] – ( 4M ) An SRS should have the following contents : 1. FUNCTIONALITY 2. ENVIRONMENT DESCRIPTION AND SYSTEM OBJECTIVES. 3. PROJECT MANAGEMENT. 4. SYSTEM DELIVERY AND INSTALLATION REQUIREMENTS. 5. FUNCTIONAL CONSTRAINTS. 6. DESIGN CONSTRAINTS.

13. *** NEED / IMPORTANCE OF SRS – (2M / 4M) It is the formal and official document. SRS resolves the conflict between user and developer. Further development of the system takes place based on SRS. This is the fundamental document, bridges the gap between user requirements and developers view.

14. 1. INTRODUCTION 1.1 Purpose 1.2 Scope 1.3 Definition, acronyms and abbreviations 1.4 References 1.5 Overview 2. GENERAL DECRIPTION 2.1 Product perspective 2.2 Product functions 2.3 User Characteristics 2.4 General constraints 2.5 Assumptions and Dependencies. 3. Specific Requirements 3.1 Functional requirements 3.2 Non-functional requirements 3.3 Interface requirements 4. Appendices 5. Index 14 OUTLINE OF SRS DOCUMENT IEEE STANDARD IEEE STANDARD STRUCTURE OF SRS DOCUMENT : [ An Outline of SRS Document ]

15. *** Requirements Engineering Processes ***

16. Requirements Engineering 16 The process of establishing the services that the customer requires from a system and the constraints under which it operates is called requirement engineering process. This is an organized and structured process with the set of activities to transform input to output followed by elicitation, validation and maintaining the requirements.

17. Activities included in Requirement Engineering Feasibility studies Requirements elicitation and analysis Requirements validation Requirements management

18. The requirements engineering process

19. 1. Feasibility studies A feasibility study decides whether or not the proposed system is worthwhile. A short focused study that checks If the system contributes to organisational objectives; If the system can be engineered using current technology and within budget; If the system can be integrated with other systems that are used.

20. 2. Elicitation and analysis Sometimes called requirements elicitation or requirements discovery. Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.

21. Requirements elicitation and analysis cont... 21 Software engineers work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc. Stages include: Requirements discovery, Requirements classification and organization, Requirements prioritization and negotiation, Requirements specification.

22. Stages : 22

23. Process activities 23 Requirements discovery Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage. Requirements classification and organisation Groups related requirements and organises them into coherent clusters. Prioritisation and negotiation Prioritising requirements and resolving requirements conflicts. Requirements specification Requirements are documented and input into the next round of the spiral.

24. Problems of Requirement Analysis 24 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 change.

25. 3. Requirement Specification Requirement collected gets transformed into structure SRS document. It defines the requirements of the proposed system. What ever you have analyzed, that has to be documented. Specification is very important as it clearly indicates what are the requirements, to develop the project.

26. 4. Requirements validation Concerned with demonstrating that the requirements define the system that the customer really wants. Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

27. Requirements Validation Techniques 27 Requirements reviews Systematic manual analysis of the requirements. Prototyping Using an executable model of the system to check requirements. Test-case generation Developing tests for requirements to check testability.

28. 5. Requirements Management 28 Requirements management is the process of managing changing requirements during the requirements engineering process and system development. New requirements emerge as a system is being developed and after it has gone into use. You need to keep track of individual requirements and maintain links between dependent requirements so that you can assess the impact of requirements changes. You need to establish a formal process for making change proposals and linking these to system requirements.

29. Requirements management planning During the requirements engineering process, you have to plan: Requirements identification How requirements are individually identified; A change management process The process followed when analysing a requirements change; Traceability policies The amount of information about requirements relationships that is maintained; CASE tool support The tool support required to help manage requirements change;

30. REQUIREMENT MANAGEMENT SRS is a created document and it has to be managed through out the development. Requirements management involves establishing and maintaining agreement between customer and developer on both technical and non-technical requirements. 1. Requirement Evolution. 2. Enduring Requirements. 3. Volatile Requirements. 4. Classification of Volatile Requirement. 5. Requirement management planning.

31. 1. REQUIREMENTS EVOLUTION A large system may take several years to specify and develop a requirement. During that time system’s environment and the business objective change and the requirements evolve to reflect this. Requirement time evolution.

32. 2. ENDURING REQUIREMENTS ( durable/lasting) These are relatively stable requirements. These requirements are derived from core activity of the organization., Example: hospital management system- requirements are usually concerned with patients, doctors, nurses and treatments. 3. VOLATILE REQUIREMENTS These are unstable requirements And are likely to change during the system development process or for the operational use Example: hospital management system- requirements resulting from health care policies, innovative surgeries, new sophisticated surgical equipment etc.

33. 4. CLASSIFICATION OF VOLATILE REQUIREMENT MUTABLE REQUIREMENTS: requirement that changes due to system environments. EMERGENT REQUIREMENTS: requirements that emerge as the customers understanding of the system development. CONSEQUENTIAL REQUIREMENTS: requirement that result from the introduction of the computer system.- new ways of working. COMPATIBILITY REQUIREMENTS: requirement that depend on other systems or business process within an organization.

34. REQUIREMENT MANAGEMENT PLANNING. 1. REQUIREMENT IDENTIFICATION : each requirement must be uniquely identified. 2. A CHANGE MANAGEMENT PROCESS : this is the set of activities that assess the impact and cost of changes. 3. TRACEABILITY POLICIES: these policies define the relationship between requirements and system design that must be recorded and those records must be maintained. CASE TOOL SUPPORT: tools that may be used for any level of development. Ex: tools may range from specialist management systems to simple database systems.

35. SYSTEM MODELS d) Object Modelling : It combines EXTENT, BEHAVIORIAL AND STRUCTURAL MODELLING Or Environment of the system is Of the system is modelled.

42. ROUNDED RECTANGLE Function processing

48. DATA MODELS ( SEMANTIC MODELS ) THIS DESCRIBES THE LOGICAL STRUCTURE OF THE DATA WHICH IS IMPORTED TO AND EXPORTED BY THE SYSTEMS. These models gives more details about the system. They need to be stored in specific storage locations and are often referred as data dictionaries where the names are stored in an alphabetical format. Example : SCHOOL INFORMATION SYSTEM. Advantages : 1. it can be applied as a mojor tool for name management. 2. it can be used to store large information at organizational level

49. OBJECT MODELS These are the models where we express the system requirements using an object model,designing using objects and developing the system in an object oriented programming languages such as java, c++, ada … These models are developed during requirement analysis. This combines the uses of data flow and semantic data models. Three types: 1. INHERITANCE MODEL 2. OBJECT AGGREGATION 3. OBJECT BEHAVIOUR MODEL

50. INHERITANCE MODEL THIS DESCRIBES THE PROCESS OF INHERITING/ ACQUIRING PROPERTIES AND BEHAVIOUR FROM ONE CLASS TO ANOTHER. OBJECT AGGREGATION A SINGLE OBJECT MAY HAVE MULTIPLE OBJECTS ASSOCIATED WITH IT. TO MODEL SUCH SITUATION WE WILL USE OBJECT AGGREGATION. APART FROM ACQUIRING ATTRIBUTE AND SERVICES THROUGH AN INHERITANCE RELATIONSHIP WITH OTHER OBJECTS, SOME OBJECTS ARE GROUPINGS OF OTHER OBJECTS. OBJECT EMBEDDED WITH ANOTHER OBJECT IS CALLED OBJECT AGGREGATION OBJECT BEHAVIOURAL MODELLING Behaviour of the individual objects and overall behavior of the object oriented systems.

51. END OF CHAPTER – 3