Software Requirements

1. Software Requirements Lecture # 1

2. Requirements • IEEE Standard 729 defines it as “(1) a condition or capability needed by a user to solve a problem or achieve an objective; (2) a condition or capability that must be met or possessed by a system...to satisfy a contract, standard, specification, or other formally imposed document”

3. Importance of Requirements • The hardest single part of building a software system is deciding what to build...No other part of the work so cripples the resulting system if done wrong. No other part is difficult to rectify later • Fred Brooks

4. Software Requirements • A complete description of what the software system will do without describing how it will do it is represented by the software requirements

5. Stakeholders • People affected in some way by the system • Documents • Existing system • Domain/business area Sources of Requirements

6. Role Of Requirements

7. Verification and Validation Testing

8. Verification and Validation Testing

9. Some Risks from Inadequate Requirement Process • Insufficient user involvement leads to unacceptable products. • Creeping user requirements contribute to overruns and degrade product quality. • Ambiguous requirements lead to ill-spent time and rework. • Gold-plating by developers and users adds unnecessary features. • Minimal specifications lead to missing key requirements. • Overlooking the needs of certain user classes (stake holders) leads to dissatisfied customers. • Incompletely defined requirements make accurate project planning and tracking impossible.

10. Ambiguous requirements • Let us consider the following requirement statement: The operator identity consists of the operator name and password; the password consists of six digits. It should be displayed on the security VDU and deposited in the login file when an operator logs into the system.

11. Gold-plating • Gold-plating refers to features are not present in the original requirement document and in fact are not important for the end-user but the developer adds them anyway thinking that they would add value to the product. Since these features are outside the initial scope of the product, adding them will result in schedule and budget overruns.

12. Minimal specifications • Let us look at the following requirement. The requirement was stated as: “We need a flow control and source control engineering tool.”

13. Levels of Software Requirements • Business Requirements • User Requirements • Functional Requirements • Non-Functional Requirements

14. Functional Requirements • Statements describing what the system does • Functionality of the system • Functional requirements capture the behavioral aspects/functions of the proposed automated system

15. Functional Requirements Example # 1 • The system shall solve a quadratic equation using the following formula x = (-b+sqrt(b2 – 4*a*c))/2*a

16. Functional Requirements Example # 2 • The user shall be able to search either the entire database of patients or select a subset from it (admitted patients, or patients with asthma, etc.)

17. Functional Requirements Example # 3 • The system shall provide appropriate viewers for the user to read documents in the document store

18. Functional Requirements Example # 4 Every order shall be allocated a unique identifier (ORDER_ID) which the user shall use to access that order

19. Functional Requirements Example # 5 The system shall allow customers to return non-perishable items within fifteen days of the purchase. A customer must present the original sale receipt to return an item

20. Comments on Examples • Notice the ambiguity in the requirement, which uses the term ‘appropriate viewers’ • This requirement does not mention the formats of documents and types of viewers, which can be used

21. Comments on Examples • Notice the ambiguity in the requirement for solving the quadratic equation. The requirement does not speak about the possibility when the value of ‘a’ is zero • x = (-b+sqrt(b2 – 4*a*c))/2*a

22. Comments on Examples • Incomplete and ambiguous requirements are open to multiple interpretations and assumptions • This can lead to the development of poor quality, or faulty, software products

23. Non-Functional Requirements - 1 • Most non-functional requirements relate to the system as a whole. They include constraints on timing, performance, reliability, security, maintainability, accuracy, the development process, standards, etc.

24. Non-Functional Requirements - 2 • Must be built into the framework of the software product • Failure to meet a non-functional system requirement may make the whole system unusable

25. Non-Functional Requirements - 3 • For example, if an aircraft system does not meet reliability requirements, it will not be certified as ‘safe’ • If a real-time control system fails to meet its performance requirements, the control functions will not operate correctly

26. Non-Functional Requirements • Non-functional requirements arise through user needs, because of budget constraints, because of organizational policies, because of the need of interoperability with other software and hardware systems, or because of external factors such as safety regulations, privacy legislation, etc.

27. Non-Functional Requirements . Non-Functional requirements Product requirements Organizational requirements External requirements

28. Non-Functional Requirements . Product requirements Efficiency requirements Usability requirements Reliability requirements Portability requirements Performance requirements Space requirements

29. Product Requirements Examples • The system shall allow one hundred thousand hits per minute on the website • The system shall not have down time of more than one second for continuous execution of one thousand hours • The System service X shall have an availability of 999/1000 or 99%. This is a reliability requirement which means that out of every 1000 requests for this service, 999 must be satisfied. • System Y shall process a minimum of 8 transactions per second. This is a performance requirement.

30. Organizational Requirements . Organizational requirements Standards requirements Implementation requirements Delivery requirements

31. Organizational Requirements Examples • The system development process and deliverable documents shall conform to the MIL-STD-2167A • Any development work sub-contracted by the development organization shall be carried out in accordance with Capability Maturity Model

32. External Requirements . External requirements Interoperability requirements Ethical requirements Legislative requirements Privacy requirements Safety requirements

33. External Requirements Examples • The system shall not disclose any personal information about members of the library system to other members except system administrators • The system shall comply with the local and national laws regarding the use of software tools

34. Security requirements • Security requirements are included in a system to ensure: • Unauthorized access to the system and its data is not allowed • Examples of security requirements are: • The access permissions for system data may only be changed by the system’s data administrator • All system data must be backed up every 24 hours and the backup copies stored in a secure location which is not in the same building as the system • All external communications between the system’s data server and clients must be encrypted

35. Examples of safety requirements • The system shall not operate if the external temperature is below 4 degrees Celsius • The system should not longer operate in case of fire • The system should no longer operate if security attacks have become obvious (relation to security requirements)

36. Interoperability • the degree to which something is connected to and operates with others. Examples • “The application shall properly interoperate with the Customer Oracle database.” • “The application shall properly interoperate with the existing Warehouse Management application.” • “The application shall properly interoperate with existing barcode readers.”

37. Observations on Non-Functional Requirements • Chances of conflicts within non-functional requirements are fairly high, because information is coming from different stakeholders. For example, different stakeholders can give different response times or failure tolerance levels, etc.

38. Requirement metrices

39. Observations on Non-Functional Requirements • Some negotiations must be done among different stakeholders, to achieve an agreement in these situations

40. Example Business Requirement • user will be able to correct spelling errors in a document efficiently. User Requirements • finding spelling errors in the document and decide whether to replace each misspelled word with the one chosen from a list of suggested words.

41. Functional Requirements • The spell checker will find and highlight misspelled words. • It will then display a dialog box with suggested replacements. • The user will be allowed to select from the list of suggested replacements. • Upon selection it will replace the misspelled word with the selected word. It will also allow the user to make global replacements.

42. Non-Functional Requirements • It must be integrated into the existing word-processor which runs on windows platform.

43. Requirement Statement and Requirement Specification Documents • The two main documents produced during this phase are Requirement Statement and Requirement Specification. They are also called Requirement Definition and Functional Specification and are used to document user requirements and functional requirements respectively.

44. Requirement Statement Characteristics • Complete - Each requirement must fully describe the functionality to be delivered. • Correct - Each requirement must accurately describe the functionality to be built. A user requirement that conflict with a corresponding system requirement isn’t correct. • Feasible - It must be possible to implement each requirement within the known capabilities and limitations of the system and its environment. • Necessary -Each requirement should document something that the customer really need or something that is required for conformance to an external system requirement or standard.

45. Requirement Statement Characteristics • Prioritized - Assign an implementation priority to each requirement, feature or use case to indicate how essential it is to a particular product release. • Unambiguous - All readers of a requirement statement should arrive at a single, consistent interpretation of it. • Verifiable - Examine each requirement to see whether you can devise a small number of tests or use other verification approaches, such as inspection or demonstration, to determine whether the requirement was properly implemented

46. Requirement Specification Characteristics • A good Requirements specification document should possess the following characteristics. Complete - No requirement or necessary information should be missing. Consistent – No requirement should conflict with other software

47. Example Functional (conflicted Requirements) System must monitor all temperatures in a chemical reactor. System should only monitor and log temperatures below -200 C and above 4000 C.

48. Continued • Modifiable - One must be able to revise the Software Requirement Specification when necessary and maintain a history of changes made to each requirement. • Traceable - One should be able to link each requirement to its origin and to the design elements, source code, and test cases that implement and verify the correct implementation of the requirement.