1. CO2401 Software Development Teaching structure –Lecture –Labs Assessment –Assignment 50% –Exam 50%

2. CO2401 Software Development Project Lifecycle Requirements HCI & GUI Design Code Testing Quality Evaluation

3. Objectives 1.To introduce the idea of system requirements and the requirements engineering process for software systems 2.To explain how requirements engineering fits into a broader system engineering process 3.To explain the importance of the system requirements document (SRS)

4. Software systems Computer systems fall into two broad categories User-configured systems where a purchaser puts together a system from existing software products Custom systems where a customer produces a set of requirements for hardware/software system and a contractor delivers that system

5. Software systems (continued) Classes of custom systems Information systems Primarily concerned with processing information Embedded systems Systems where software is used as a controller in a hardware system (e.g. video camera) Command and control systems A combination of information systems and embedded systems where special purpose computers provide information which is collected and stored and used to make decisions

6. Terminology System requirements Define what the system is required to do and constraints under which it will be required to operate Requirements engineering The structured set of activities involved in developing system requirements (are accountable for approx 15% of system development costs) Requirements document The formal statement of system requirements System stakeholders Anyone affected by the system Requirements management The processes involved in making changes to requirements

7. Requirements document structure IEEE/ANSI 830-1993 standard recommended structure for software requirements documents 1Introduction 1.1Purpose of document 1.2Scope of the product 1.3Definitions, acronyms and abbreviations 1.4References 1.5Overview of the remainder of the document

8. Requirements document structure 2General description 2.1Product perspective 2.2Product functions 2.3User characteristics 2.4General constraints 2.5Assumptions and dependencies 2.6Apportioning of requirements 3Specific requirements - Covering functional, non-functional and interface requirements 4Appendices 5Index

9. Requirements document structure 1Introduction 1.1Purpose This sub-section should –Describe the purpose of the SRS –Specify the intended audience of the SRS

10. Requirements document structure 1Introduction 1.2Scope This sub-section should –Identify the software product(s) to be produced by name –Explain what the software product(s) will do and not do –Describe the application of the software including benefits, objectives and goals –Be consistent with higher level specifications if they exist

11. Requirements document structure 1Introduction 1.3Definitions, acronyms and abbreviations This sub-section should –Provide the definitions of all terms a complete list of all terms, acronyms and abbreviations required to properly interpret the SRS –This information may be provided by reference to one or more appendixes in the SRS or reference to other documents

12. Requirements document structure 1.Introduction 1.4References This sub-section should –Provide a complete list of documents referenced elsewhere in the SRS –Identify each document by title, report number (if applicable), date and publishing organisation –Specify the sources from which the references can be obtained

13. Requirements document structure 1.Introduction 1.5Overview This sub-section should –Describe what the rest of the SRS should contain –Explain how the SRS is organised

14. Requirements document structure 2General description 2.1Product perspective 2.2Product functions 2.3User characteristics 2.4General constraints 2.5Assumptions and dependencies 2.6Apportioning of requirements 3Specific requirements - Covering functional, non-functional and interface requirements 4Appendices 5Index

15. Requirements document structure 2.General description 2.1 Product perspective This sub-section should Put the product in perspective with other related products If the product is totally self-contained it should be stated here. If the product is a component of a larger system, functionality of the software to the requirements of the larger system should be stated and interfaces between the two systems should be stated. Block diagrams may be useful for showing components and interfaces of two systems.

16. Requirements document structure 2.General description 2.1 Product perspective (continued) This sub-section should also describe how the software operates inside various constraints. For example, these could include: System interfaces User interfaces Hardware interfaces Software interfaces Communication interfaces Memory Operations Site adaptation requirements

17. Requirements document structure 2.General description 2.2 Product functions This sub-section provides a summary of the major functions that the software will perform. For example, and SRS for an accounting program may use this part to address customer account maintenance, customer statement and invoice preparation. For the sake of clarity: The functions should be organised in a way that makes them understandable to anyone reading the document Textual or graphical methods can be used to show the functions and their relationships. Such a diagram is not intended to show a design of the product, but simply shows the logical relationships among variables.

18. Requirements document structure 2.General description 2.3 Constraints This sub-section should provide a general description of any other items that will limit the developers options. These include: Regulatory policies Hardware limitations Interfaces to other applications Reliability requirements Criticality of the application Safety and security considerations

19. Requirements document structure 2.General description 2.4 Assumptions and dependencies This sub-section should list each of the factors that affect the requirements stated in the SRS.provide a general description of any other items that will limit the developers options. These include: Regulatory policies Hardware limitations Interfaces to other applications Reliability requirements Criticality of the application Safety and security considerations

20. Requirements document structure 2.General description 2.5 Apportioning of requirements This sub-section should identify requirements that may be delayed until future versions of the system

21. Requirements document structure 3.Specific requirements This section of the SRS should contain all the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements.

22. Requirements document structure 3.Specific requirements (continued) These requirements should include at a minimum a description of every input (stimulus) into the system, every output (response) from the system, and all functions performed by the system in response to an input or in support of an output.

23. Requirements document structure 3.Specific requirements As this is often the largest and most important part of the SRS, the following principles apply: a)Specific requirements should be stated in conformance with all the characteristics described in the section titled “Characteristics of a good SRS” b)Specific requirements should be cross-referenced to earlier documents that relate c)All requirements should be uniquely identifiable d)Careful attention should be given to organising the requirements to maximise readability

24. Requirements document structure 3.Specific requirements The items that compromise requirements are: 3.1 External interfaces 3.2 Functions 3.3 Performance requirements 3.4 Logical database requirements 3.5 Design constraints 3.6 Software system attributes 3.7 Organising the specific requirements

25. Requirements document structure 3.Specific requirements 3.1 External interfaces This part should contain a detailed description of all inputs into and outputs from the software system. It should complement the interface descriptions from section 2 of the document and should not repeat the information from there

26. Requirements document structure 3.Specific requirements 3.1 External interfaces (continued) This part should include both content and format as follows: a)Name of item b)Description of purpose c)Source of input or destination of output d)Valid range, accuracy and/or tolerance e)Units of measure f)Timing

27. Requirements document structure 3.Specific requirements 3.1 External interfaces (continued) g)Relationships to other inputs/outputs h)Screen formats/organisation i)Window formats/organisation j)Data formats k)Command formats l)End messages

28. Requirements document structure 3.Specific requirements 3.2 Functions Functional requirements should define the fundamental actions that must take place in the software in accepting and processing the inputs and and in processing and generating the outputs. Functional requirements are generally listed as “shall” statements starting with “The system shall…”

29. Requirements document structure 3.Specific requirements 3.2 Functions (continued) Functional requirements include: a)Validity checks on the inputs b)Exact sequence of operations c)Responses to abnormal situations (e.g., overflow, communication facilities, error handling and recovery) d)Effect of parameters e)Relationship of inputs to outputs, including i.Input/output sequences ii.Formulas for input to output conversion

30. Requirements document structure 3.Specific requirements 3.3 Performance requirements This subsection should specify both the static and dynamic numerical requirements placed on the software or on the human interaction with the software as a whole. Static numerical requirements are sometimes identified under a separate section titled “Capacity”

31. Requirements document structure 3.Specific requirements 3.3 Performance requirements (continued) Static numerical requirements may include the following: a)The number of terminals to be supported b)The number of simultaneous users to be supported c)Amount and type of information to be handled

32. Requirements document structure 3.Specific requirements 3.3 Performance requirements (continued) Dynamic numerical requirements may include the following: a)The numbers of transactions and tasks b)The amount of data to be processed within certain time periods for both normal and peak workload conditions

33. Requirements document structure 3.Specific requirements 3.3 Performance requirements (continued) All performance requirements should be stated in measurable terms: For example: 95% of the transactions shall be processed in less than one second Rather than: An operator shall not have to wait for the transaction to complete Note: Numerical limits applied to one specific function are normally specified as part of the processing subparagraph description of that function

34. Requirements document structure 3.Specific requirements 3.4 Logical database requirements This part should specify the logical requirements for any information that is to be placed in a database. This may include the following: a)Types of information used by various functions b)Frequency of use c)Accessing capabilities d)Data entities and their relationships e)Integrity constraints f)Data retention requirements

35. Requirements document structure 3.Specific requirements 3.5 Design constraints This part should specify design constraints that can be imposed by other standards, hardware limitations etc 3.5.1 Standards compliance The standards section should specify the requirements derived from existing standards or regulations. They may include the following: a)Report format b)Data naming c)Accounting procedures d)Audit tracing e.g. this could specify a requirement for software to trace processing activity

36. Requirements document structure 3.Specific requirements 3.6 Software system attributes There are a number of attributes of software that can serve as requirements. It is important that required attributes can be specified so that their achievement can be verified. The following is a partial list of examples: 3.6.1 Reliability 3.6.2 Availability 3.6.3 Security 3.6.4 Maintainability 3.6.5 Portability

37. Requirements document structure 3.Specific requirements 3.6 Software system attributes 3.6.1 Reliability Should specify the factors required to establish the required reliability of the software system at the time of delivery 3.6.2 Availability Should specify the factors required to guarantee a defined availability level for the entire system such as checkpoint, recovery and restart

38. Requirements document structure 3.Specific requirements 3.6 Software system attributes 3.6.3 Security Should specify the factors that protect the software from accidental or malicious access, use, modification, destruction, or disclosure. Specific requirements in this area could include the need to: a)Utilise certain cryptographical techniques b)Keep specific log or history data sets c)Assign certain functions to different modules d)Restrict communications between some areas of the program e)Check data integrity for critical variables

39. Requirements document structure 3.Specific requirements 3.6 Software system attributes 3.6.4 Maintainability Should specify attributes of software that relate to the ease of maintenance of the software itself. There may be some requirement for certain modularity, interfaces, complexity etc Note: Requirements should not be placed her because just because they are thought to be good design practises

40. Requirements document structure 3.Specific requirements 3.6 Software system attributes 3.6.5 Portability Should specify attributes of software that relate to the ease of porting the software to other host machines and/or operating systems. This may include the following: a)Percentage of components with host dependant code b)Percentage of code that is host dependant c)Use of a proven portable language d)Use of a particular compiler or language subset e)Use of a particular operating system

41. Requirements document structure 3.Specific requirements 3.6 Software system attributes 3.6.5 Portability Should specify attributes of software that relate to the ease of porting the software to other host machines and/or operating systems. This may include the following: a)Percentage of components with host dependant code b)Percentage of code that is host dependant c)Use of a proven portable language d)Use of a particular compiler or language subset e)Use of a particular operating system

42. Requirements document structure 3.Specific requirements 3.7 Organising the specific requirements For anything but trivial systems the detailed requirements tend to be extensive. For this reason, it is recommended that careful consideration is given to organising these in manner optimal to understanding. There is no one optimal organisational for all systems. Different classes of systems lend themselves to different organisations of requirements in section 3 of the SRS.