Senior Design – Requirements Specification Review

1. Senior Design – Requirements Specification Review The goal is to specify: what is to be accomplished how the system or product fits into the needs of the business how the system is to be used on a day-to-day basis Sounds simple, reality is it is quite difficult. Specification can mean different things to different people. A specification can be written as: a written document a set of graphical models a formal mathematical model a collection of usage scenarios a prototype any combination of these. We use a combination of these.

2. Senior Design – Requirements Document Review REQUIREMENTS DOCUMENT STRUCTURE • Introduction (Requirements Definition) • Describe need for the system and how it fits with business objectives. • Functional Requirements • Describe the services to be provided in detail. May include, use cases, state diagrams, and other graphical representations. • Non-functional Requirements • Define constraints on the system and the development process. • System Evolution • Define fundamental assumptions on which the system is based and anticipated changes. • Glossary • Define technical terms used. • Index

3. Senior Design – Requirements Document Review REQUIREMENTS DEFINITON • A statement in natural language of the services the system provides and its operational constraints. • Written for customers. • Example: TheraWii from 2009 • There is an emerging trend toward using video games as a means of increasing patient engagement in physical therapy. This trend is primarily driven by the newest generation of consumer console systems which use motion-based controls. However, clinical research into the efficacy of these systems is hindered by the inability to automatically collect data from systems and software which were not intended for this purpose. • We will create a new piece of software that will give researchers the ability to experiment and quantitatively assess the value of game-based therapy. This software will provide an extensible framework for games or interactive experiments as well as an example suite of activities. The key aspect of this framework will allow researchers to easily gather data from motion-based input controls such as the Wii Remote. Various reporting methods and analysis tools will be provided for the gathered data.

4. Senior Design – Requirements Specification Review Requirements may be functional or non-functional Functional requirements describe system services or features. The key is to remember it is about the WHAT not the HOW of your project. One exception to this, IMHO, is the user interface. I prefer to see most of it dictated in the requirements document, because it is a great tool to help the end-user understand what you are developing.

5. Senior Design – Requirements Specification Review Functional Requirement Examples r3.1 The software shall keep a persistent set of menus at the top of the Therapy/Prole window. Priority 1 r3.2 The software shall list the menu options as text horizontally across the top of the window. Priority 1 r3.3 File Menu r3.3.1 The software shall display a drop down menu when the \File" menu is clicked on. Priority 1 r3.3.2 The software shall have an \Import Therapies..." option in the File menu. Priority 1 r3.3.3 The software shall have an \Export Therapies..." option in the File menu. Priority 1 r3.3.4 The software shall have an \Import Profiles..." option in the File menu. Priority 1 r3.3.5 The software shall have an \Export Profiles..." option in the File menu. Priority 1 r3.3.6 The software shall bring up the appropriate import or export dialog if any of the Import or Export menu options is clicked on (see [4.3.6]). Priority 1 r3.3.7 The software shall have a \Quit" option in the File menu. Priority 1 r3.3.8 The software shall exit the program if the \Quit" option is clicked by the user. Priority 1

6. Senior Design – Requirements Specification Review Non-functional requirements is a constraint on the system or on the development process. This may include some description of the HOW. Non-functional requirements may include: security standards system properties and constraints e.g., reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. process requirements may also be specified mandating a particular CASE system, programming language or development method. Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.

7. Senior Design – Requirements Document Review • Requirements Specification • A structured document setting out detailed descriptions of the system services. • Written as a contract between client and contractor. • Written for contractors and developers.

8. Senior Design – Requirements Document Review How do you Validate that you’ve done a good job? You might think that quality is hard to quantify during requirements engineering. After all, how can you determine if what the end-user/customer is telling you is correct? However you can check for: ambiguity conflicts omissions (some, obviously not all)

9. Software Engineering – Requirements Engineering Traceability Every requirement is given a unique identifier. This helps with traceability. You can include any of the following diagrams: Source traceability table: identifies the source of each requirement Dependency traceability table: identifies how requirements are related to another Subsystem traceability table: Categorizes requirements by the subsystems they govern. Interface traceability table: relates requirements to both internal and external interfaces.

10. Software Engineering – Requirements Engineering ELICITING REQUIREMENTS – USER REQUIREMENTS It is helpful to create scenarios that identify a thread of usage for the system to be constructed. These scenarios are often called use cases. Use cases tell a story about how an end user interacts with the system under a specific set of circumstances. This story may be: narrative text an outline of tasks or interactions a template-based description diagrammatic representation It depicts software from an end-user point of view.

11. Software Engineering – Requirements Engineering DEVELOPING USE CASES “A use case captures a contract.. [that] describes the system’s behavior under various conditions as the system’s behavior under various conditions as the system responds to a request from one of its stakeholders.” Steps in creating a use case: Step One: Define the actors that will be in involved in the story. Actors are different people (or devices) that use the system or product within the context of the function/behavior that is to be described. Actors represent the roles that people (or devices) play as the system operates. An actor is anything that communicates with the system or product. Note, an actor and an end-user are not necessarily the same thing. End-users may play many roles. An actor plays one role in the context of a use-case.

12. Software Engineering – Requirements Engineering DEVELOPING USE CASES Questions to ask about actors: Who are the actor(s)? What are the actor’s goals? What preconditions should exist before the story begins? What exceptions might be considered as the story is described? What variations in the actor’s interaction are possible? What type of system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected change?

13. Software Engineering – Requirements Engineering DEVELOPING USE CASES Think about a home security system.

14. Software Engineering – Requirements Engineering DEVELOPING USE CASES Think about a home security system. Three actors exist: homeowner/configuration manager, sensors, and the monitoring subsystem. Let’s look at the homeowner. The homeowner interacts with the home security function in a number of different ways using either the alarm control panel or a PC: Enters a password to allow all other interactions. Inquires about the status of a security zone. Inquiries about the status of a sensor. Presses the panic button in an emergency. Activates/deactivate the security system.

15. Software Engineering – Requirements Engineering DEVELOPING USE CASES Use case: InitiateMonitoring Primary Actor: Homeowner Goal in context: To set the system to monitor sensors when the homeowner leaves the house or remains inside. Preconditions: System was programmed for a password and to recognize various sensors. Trigger: The homeowner decides to “set” the system, i.e turn on the alarm function. Scenario: Homeowner observes control panel. Homeowner enters password. Homeowner selects ‘stay” or “away” Homeowner observes red alarm light to indicate that SafeHome has been armed

16. Software Engineering – Requirements Engineering DEVELOPING USE CASES Exceptions: Control panel is not ready: Homeowner checks all sensors to determine which are open and closes them. Password is incorrect (control panel beeps once) homeowner renters correct password. Password not recognized: monitoring and response subsytem must be contacted to reprogram password Stay is selected: control panel beeps twice and a stay light is lit; perimeter sensors are activated Away is selected. Control panel beeps three times and an away light is lit; all sensors are activated Priority: Essential, must be implemented When available: First Increment Frequency of use: Many times a day Channel to actor: via control panel

17. Software Engineering – Requirements Engineering DEVELOPING USE CASES Secondary Actors: support technician, sensors. Open issues: Should there be a way to activate the system without the use of a password or with an abbreviated password? Should the control panel display additional text messages? Ho w much time does the homeowner have to enter a password from the time the first key is pressed? Is there a way to deactivate the system before it activates?

18. Software Engineering – Requirements Engineering DEVELOPING USE CASES

19. Software Engineering – Requirements Engineering BUILDING THE ANALYSIS MODEL An analysis model provides a description of the required information, functional , and behavioral domains for a computer based system. An analysis model will change during the requirements gathering with some areas stable and others being volatile. There are many ways to represent the model. Scenario-based elements: The system is described from the user’s point of view.

20. Software Engineering – Requirements Engineering DEVELOPING USE CASES Each usage scenario implies a set of “objects” that are manipulated as an actor interacts with them.

21. Software Engineering – Requirements Engineering DEVELOPING USE CASES The behavior of a computer- based system can have a profound effect on the design that is chosen, therefore the analysis model must provide modeling elements that depict behavior:

22. Software Engineering – Requirements Engineering WRITING THE REQUIREMENTS DOCUMENT • Natural language relies on the specification readers and writers using the same words for the same concept. • A natural language specification is over-flexible and subject to different interpretations. • Requirements are not partitioned by language structures.

23. Software Engineering – Requirements Engineering WRITING THE REQUIREMENTS DOCUMENT DOCUMENT STRUCTURE • Natural language is typically used when writing requirements definitions. • This is universally understandable but three types of problem can arise: • 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

24. Software Engineering – Requirements Engineering WRITING THE REQUIREMENTS DOCUMENT DOCUMENT STRUCTURE • Requirements definition • Customer-oriented descriptions of the system’s functions and constraints on its operation. • Requirements specification • Precise and detailed descriptions of the system’s functionality and constraints. • Intended to communicate what is required to system developers and serve as the basis of a contract for the system development.

25. Software Engineering – Requirements Engineering WRITING THE REQUIREMENTS DOCUMENT STRUCTURED LANGUAGE • A limited form of natural language may be used to express requirements. • This removes some of the problems resulting from ambiguity and flexibility and imposes a degree of uniformity on a specification. • Often best supported using a forms-based approach.

26. Software Engineering – Requirements Engineering EXAMPLES OF 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.

27. Software Engineering – Requirements Engineering FORM-BASED FUNCTION SPECIFICATION • Definition of the function or entity. • Description of inputs and where they come from. • Description of outputs and where they go to. • Indication of other entities required. • Pre and post conditions (if appropriate).

28. Software Engineering – Requirements Engineering FORM-BASED FUNCTION SPECIFICATION

29. Software Engineering – Requirements Engineering NON FUNCTIONAL REQUIREMENTS

30. Software Engineering – Requirements Engineering NON FUNCTIONAL REQUIREMENTS – EXAMPLES • Product requirement • 4.C.8 It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set • Organisational requirement • 9.3.2 The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95 • External requirement • 7.6.5 The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system

31. Software Engineering – Requirements Engineering NON FUNCTIONAL REQUIREMENTS – SYSTEM LEVEL Some requirements place constraints on the system as a whole rather than specific system functions. • Example • The time required for training a system operator to be proficient in the use of the system must not exceed 2 working days. • These may be emergent requirements which cannot be derived from any single sub-set of the system requirements

32. Software Engineering – Requirements Engineering REQUIREMENTS TRACEABILITY • Requirements traceability means that related requirements are linked in some way and that requirements are (perhaps) linked to their source. • Traceability is a property of a requirements specification which reflects the ease of finding related requirements. • Assign a unique number to all requirements. • Cross-reference related requirements using this unique number. • Use HTML hyperlinks to implement traceability.

33. Software Engineering – Requirements Engineering REQUIREMENTS VERIFIABILITY • Requirements should be written so that they can be verified objectively. • 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.

34. Software Engineering – Requirements Engineering Requirements Measures