Software Requirements Document PDF

Software Requirements Document 1 Key points Identify the major components of the requirements document Identify the major problems that might exist in the requirements document The requirements document validation IEEE requirements document standar...

Software Requirements Document 1 Key points Identify the major components of the requirements document Identify the major problems that might exist in the requirements document The requirements document validation IEEE requirements document standards 2 The requirements document The requirements document is the official statement of what is required of the system developers Should include both a definition and a specification of 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 3 Guidelines for writing requirements Invent a standard format and use it for all requirements. Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements. Use text highlighting to identify key parts of the requirement Avoid the use of computer jargon 4 Requirements document requirements Specify external system behaviour Specify implementation constraints Easy to change Record forethought about the life cycle of the system i.e. predict changes Characterise responses to unexpected events 5  Complex Problems Problems which are so complex that they can never be fully understood and where understanding develops during the system development. Therefore, requirements are normally both incomplete and inconsistent 6  Reasons for inconsistency Large software systems must improve the current situation. It is hard to anticipate the effects that the new system will have on the organization Different users have different requirements and priorities. System end-users and organizations who pay for the system have different requirements. 7 Requirements Completeness A requirements document is complete if it includes all of the significant requirements, whether relating to functionality, performance, design constraints attributes or external interfaces. They should include descriptions of all facilities required. If some specification is not specified, it will open the door for assumptions. 8 Requirements ambiguity Problems arise when requirements are not precisely stated. (Ex, the software should accept too many users, considered ambiguous). Ambiguous requirements may be interpreted in different ways by developers and users. (I believe 50 is too many, while somebody else think that 50 is too few). 9 Ambiguity The difficulty of ambiguity stems from the use of natural language which in itself is inherently ambiguous. There is one and only one interpretation for every requirement. Requirement statements should be short, explicit, precise and clear. A glossary should be used when a term used in a particular context could have multiple meanings (I.e. “the user”). The fit criteria is a quantification of the requirement, which can be used to test the solution. 10 Problems with NL specification Ambiguity  The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult Over-flexibility  The same thing may be said in a number of different ways in the specification Lack of modularisation  NL structures are inadequate to structure system requirements 11 Alternatives to NL specification Notation Description Structured This approach depends on defining standard forms or natural templates to express the requirements specification. language Design This approach uses a language like a programming description language but with more abstract features to specify the languages requirements by defining an operational model of the system. Graphical A graphical language, supplemented by text annotations is notations used to define the functional requirements for the system. More recently, use-case descriptions have been used. Mathematical These are notations based on mathematical concepts specifications such as finite-state machines or sets. These unambiguous specifications reduce the arguments between customer and contractor about system functionality. However, most customers don’t understand formal specifications and are reluctant to accept it as a system contract. 12 Correctness Each requirement statement accurately represents the functionality required of the system to be built. 13 Viability Viable requirements are those that comply with the project’s constraints. Do you have the technological skills to build the requirement? Do you have the time and the money to build the requirement? Is the requirement acceptable to all stakeholders? Software Requirements 14  Requirements rationale It is important to provide rationale with requirements This helps the developer understand the application domain and why the requirement is stated in its current form Particularly important when requirements have to be changed. The availability of rationale reduces the chances that change will have unexpected effects 15  Requirements verifiability Requirements should be written so that they can be objectively verified The problem with this requirement is its use of vague terms such as ‘errors shall be minimized”  The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized. The error rate should be been quantified  Experienced controllers should be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users should not exceed two per day. 16 Requirements separation Functional and non-functional requirements should, in principle, be distinguished in a requirements specification It is sometimes difficult to decide if a requirement is functional or a non-functional  For example, requirements for safety are concerned with non-functional properties but may require functions to be added to the system 17 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 Prototyping is an important technique of requirements validation 18 Requirements checking Validity. Does the system provide the functions which best support the customer’s needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology. 19 Requirements reviews Regular reviews should be held while the requirements definition is being formulated. Both client and contractor staff should be involved in reviews. Good communications between developers, customers and users can resolve problems at an early stage. 20 Requirements document changes The requirements document should be organized so that requirements changes can be made without extensive rewriting External references should be minimized and the document sections should be as modular as possible. Changes are easiest when the document is electronic. Lack of standards for electronic documents make this difficult. 21 IEEE requirements standard Introduction General description Specific requirements Appendices Index This is a generic structure that must be instantiated for specific systems 22  Introduction – Purpose – Scope – Definitions, acronyms, and IEEE abbreviations Recommen – References – Overview ds Overall Description – Product perspective – Product functions – User characteristics – Constraints – Assumptions and Dependencies Specific Requirements Appendixes Index 23