Senior Design Requirements Specification Review REQUIREMENTS SPECIFICATION The

  • Slides: 41
Download presentation
Senior Design – Requirements Specification Review REQUIREMENTS SPECIFICATION The goal is to specify: u

Senior Design – Requirements Specification Review REQUIREMENTS SPECIFICATION The goal is to specify: u u u 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: u u u 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.

Senior Design – Requirements Specification Review REQUIREMENTS DOCUMENT STRUCTURE u Introduction (Requirements Definition) –

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

Senior Design – Requirements Specification Review REQUIREMENTS DEFINITON A statement in natural language of

Senior Design – Requirements Specification Review REQUIREMENTS DEFINITON A statement in natural language of the services the system provides and its operational constraints. Written for customers. Example: Thera Wii 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.

Senior Design – Requirements Specification Review REQUIREMENTS SPECIFICATION A structured document setting out detailed

Senior Design – Requirements Specification 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.

Senior Design – Requirements Specification Review Requirements may be functional or non-functional Functional requirements

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.

Senior Design – Requirements Specification Review Functional Requirement Examples (Future Tense) r 3. 1

Senior Design – Requirements Specification Review Functional Requirement Examples (Future Tense) r 3. 1 The software shall keep a persistent set of menus at the top of the Therapy/Profile window. Priority 1 r 3. 2 The software shall list the menu options as text horizontally across the top of the window. Priority 1 r 3. 3 File Menu r 3. 3. 1 The software shall display a drop down menu when the File" menu is clicked on. Priority 1 r 3. 3. 2 The software shall have an Import Therapies. . . " option in the File menu. Priority 1 r 3. 3. 3 The software shall have an Export Therapies. . . " option in the File menu. Priority 1 r 3. 3. 4 The software shall have an Import Profiles. . . " option in the File menu. Priority 1 r 3. 3. 5 The software shall have an Export Profiles. . . " option in the File menu. Priority 1 r 3. 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 r 3. 3. 7 The software shall have a Quit" option in the File menu. Priority 1 r 3. 3. 8 The software shall exit the program if the Quit" option is clicked by the user. Priority 1

Senior Design – Requirements Specification Review Functional Requirement Examples (Present Tense) r 3. 1

Senior Design – Requirements Specification Review Functional Requirement Examples (Present Tense) r 3. 1 The software keeps a persistent set of menus at the top of the Therapy/Profile window. Priority 1 r 3. 2 The software lists the menu options as text horizontally across the top of the window. Priority 1 r 3. 3 File Menu r 3. 3. 1 The software displays a drop down menu when the File" menu is clicked on. Priority 1 r 3. 3. 2 The software has an Import Therapies. . . " option in the File menu. Priority 1 r 3. 3. 3 The software has an Export Therapies. . . " option in the File menu. Priority 1 r 3. 3. 4 The software has an Import Profiles. . . " option in the File menu. Priority 1 r 3. 3. 5 The software has an Export Profiles. . . " option in the File menu. Priority 1 r 3. 3. 6 The software brings 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 r 3. 3. 7 The software has a Quit" option in the File menu. Priority 1 r 3. 3. 8 The software exits the program if the Quit" option is clicked by the user. Priority 1 It is a matter of style whether you write the requirements document in future or present tense. As I believe the real value in the requirements document is as time moves on and the application was completed and now is modified. However, I believe that since the period of time the document will be used most is potentially after development, I would write it in the active voice as above.

Senior Design – Requirements Specification Review Functional Requirement Examples (Priorities) Priority Level Description Priority

Senior Design – Requirements Specification Review Functional Requirement Examples (Priorities) Priority Level Description Priority 1 Essential and required functionality Priority 2 Desirable functionality Priority 3 Extra features

Senior Design – Requirements Specification Review REQUIREMENTS VERIFIABILITY u Requirements should be written so

Senior Design – Requirements Specification Review REQUIREMENTS VERIFIABILITY u Requirements should be written so that they can be verified objectively. u 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. u 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.

Software Engineering – Requirements Engineering REQUIREMENTS VERIFIABILITY Property Measure Speed Processed Transactions/Second User/Event Response

Software Engineering – Requirements Engineering REQUIREMENTS VERIFIABILITY Property Measure Speed Processed Transactions/Second User/Event Response Time Screen Refresh Time Size K Bytes Number of RAM Chips Ease of Use Training Time Number of Help Frames Reliability Mean Time to Failure Probability of Unavailability Rate of Failure Occurrence Availability Robustness Time to Restart After Failure Percentage of Events Causing Failure Probability of Data Corruption on Failure Portability Percentage of Target Dependent Statements Number of Target Systems

Senior Design – Requirements Specification Review USE CASES It is helpful to create scenarios

Senior Design – Requirements Specification Review USE CASES 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: u u narrative text an outline of tasks or interactions a template-based description diagrammatic representation It depicts software from an end-user point of view.

Software Engineering – Requirements Engineering DEVELOPING USE CASES “A use captures a contract. .

Software Engineering – Requirements Engineering DEVELOPING USE CASES “A use captures a contract. . [that] describes 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.

Software Engineering – Requirements Engineering DEVELOPING USE CASES Questions to ask about actors: Who

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

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

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

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

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: u u u 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.

Software Engineering – Requirements Engineering DEVELOPING USE CASES Use case: Initiate. Monitoring Primary Actor:

Software Engineering – Requirements Engineering DEVELOPING USE CASES Use case: Initiate. Monitoring 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: u Homeowner observes control panel. u Homeowner enters password. u Homeowner selects ‘stay” or “away” u. Homeowner observes red alarm light to indicate that Safe. Home has been armed

Software Engineering – Requirements Engineering DEVELOPING USE CASES Exceptions: 1. Control panel is not

Software Engineering – Requirements Engineering DEVELOPING USE CASES Exceptions: 1. Control panel is not ready: Homeowner checks all sensors to determine which are open and closes them. 2. Password is incorrect (control panel beeps once) homeowner renters correct password. 3. Password not recognized: monitoring and response subsytem must be contacted to reprogram password 4. Stay is selected: control panel beeps twice and a stay light is lit; perimeter sensors are activated 5. 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

Software Engineering – Requirements Engineering DEVELOPING USE CASES Secondary Actors: support technician, sensors. Open

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

Software Engineering – Requirements Engineering DEVELOPING USE CASES

Software Engineering – Requirements Engineering DEVELOPING USE CASES

Software Engineering – Requirements Engineering DEVELOPING USE CASES Are use cases always helpful? I

Software Engineering – Requirements Engineering DEVELOPING USE CASES Are use cases always helpful? I am a strong believer that use cases that do not add to the understanding of a project are a waste of space and can detract from the formal specifications. So when are use cases useful? When the domain is not clear. For example see the following video: http: //www. youtube. com/watch? v=pf. Ys 5 C 8 D 4 uk How do we specify a system that accomplishes an ad-hoc network like that? Sure we can try to specify it all in words, but here is where a use case is extremely valuable. See how the Intelligent Tactical Mesh Networks project used use cases.

Software Engineering – Requirements Engineering DEVELOPING USE CASES First, they defined the symbols used.

Software Engineering – Requirements Engineering DEVELOPING USE CASES First, they defined the symbols used.

Software Engineering – Requirements Engineering DEVELOPING USE CASES Symbols continued:

Software Engineering – Requirements Engineering DEVELOPING USE CASES Symbols continued:

Software Engineering – Requirements Engineering DEVELOPING USE CASES First Use Case:

Software Engineering – Requirements Engineering DEVELOPING USE CASES First Use Case:

Software Engineering – Requirements Engineering DEVELOPING USE CASES First Use Case:

Software Engineering – Requirements Engineering DEVELOPING USE CASES First Use Case:

Software Engineering – Requirements Engineering DEVELOPING USE CASES First Use Case:

Software Engineering – Requirements Engineering DEVELOPING USE CASES First Use Case:

Software Engineering – Requirements Engineering DEVELOPING USE CASES Another Use Case:

Software Engineering – Requirements Engineering DEVELOPING USE CASES Another Use Case:

Software Engineering – Requirements Engineering DEVELOPING USE CASES Another Use Case:

Software Engineering – Requirements Engineering DEVELOPING USE CASES Another Use Case:

Software Engineering – Requirements Engineering DEVELOPING USE CASES Another Use Case:

Software Engineering – Requirements Engineering DEVELOPING USE CASES Another Use Case:

Software Engineering – Requirements Engineering DOCUMENTING THE USER INTERFACE Example Global Basketball Network: Create

Software Engineering – Requirements Engineering DOCUMENTING THE USER INTERFACE Example Global Basketball Network: Create a new posting for the Ecommerce System Requirements 4. 5. 2. 1 - A textbox for the posting’s title. This is limited to 80 plaintext characters. 4. 5. 2. . 2 - A textbox for the desired price. This is limited to 20 plaintext characters. The user may enter a range of values in any currency. 4. 5. 2. 3 - The price is optional and may be left blank. A 4. 5. 2. 4 – A textbox for the zip code location of the item. This is limited to 5 numerical characters. 4. 5. 2. 5 - A combo box for the user to select the category. 4. 5. 2. 6 - The user must select a category. 4. 5. 2. 7 - A combo box for the user to select the subcategory. Defaults to Miscellaneous. 4. 5. 2. 8 A text area for the description of the item. This is limited to 1024 plaintext characters. .

Software Engineering – Requirements Engineering DOCUMENTING THE USER INTERFACE Example Global Basketball Network:

Software Engineering – Requirements Engineering DOCUMENTING THE USER INTERFACE Example Global Basketball Network:

Software Engineering – Analysis Modeling SCENARIO BASED-MODELING Similar to a flowchart: • Round rectangles

Software Engineering – Analysis Modeling SCENARIO BASED-MODELING Similar to a flowchart: • Round rectangles imply specific system functions • Arrows represent flow through the system • Diamonds depict a branching decision

Software Engineering – Analysis Modeling SCENARIO BASED-MODELING Swim Lane Diagram Represents flow of activities

Software Engineering – Analysis Modeling SCENARIO BASED-MODELING Swim Lane Diagram Represents flow of activities indicating which actor has responsibility for the action. Responsibilities are represented as parallel segments that divide the diamond vertically, like the lanes in a swimming pool.

Software Engineering – Requirements Engineering SCENARIO BASED MODELING ACTIVITY DIAGRAM Demonstrating how the system

Software Engineering – Requirements Engineering SCENARIO BASED MODELING ACTIVITY DIAGRAM Demonstrating how the system will work

Software Engineering – Requirements Engineering Formal Specification function Search ( X: array 1. .

Software Engineering – Requirements Engineering Formal Specification function Search ( X: array 1. . N of INTEGER; Key: INTEGER ) return INTEGER ; Pre: 1 £ i £ N · X[i] = Key Post: X’ [Search (X, Key)] = Key Ù X = X’ Ù Key’ = Key

Senior Design – Requirements Specification Review Non-functional requirements is a constraint on the system

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: u security standards u system properties and constraints e. g. , reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. u 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.

Senior Design – Requirements Specification Review NON FUNCTIONAL REQUIREMENTS – EXAMPLES 4. 6. 1

Senior Design – Requirements Specification Review NON FUNCTIONAL REQUIREMENTS – EXAMPLES 4. 6. 1 Software Constraints • The software will rely on the Microsoft. Net Framework. It is assumed that any system running this software has the Microsoft. Net 2. 0 or greater correctly installed. • All drivers must be installed and configured for the Bluetooth USB receiver(s). 4. 6. 2 Hardware Constraints • Minimum of one available USB slot • One Bluetooth USB per Wii input device • Keyboard and mouse • Monitor or other video display device • 100 MB hard disk space • 256 MB available memory • 1 GHz processor • 64 MB video card 4. 6. 3 Acceptance Constraints • Before accepting the system, the developers must complete the following: • Demo the working system and any features upon request. • Prove that all Priority 1 functional requirements are met. • Provide sufficient test cases to show that the system is complete and correct.

Senior Design – Requirements Specification Review VALIDATION How do you Validate that you’ve done

Senior Design – Requirements Specification Review VALIDATION 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: u ambiguity u conflicts u omissions (some, obviously not all)

Senior Design – Requirements Specification Review TRACEABILITY Every requirement is given a unique identifier.

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

Software Engineering – Requirements Engineering BUILDING THE ANALYSIS MODEL An analysis model provides a

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.

Senior Design – Requirements Specification Review GLOSSARY List any definitions, acronyms or abbreviations used

Senior Design – Requirements Specification Review GLOSSARY List any definitions, acronyms or abbreviations used within your document. 2. 3 Definitions, Acronyms, Abbreviations 2. 3. 1 Physical Therapy . . . • Posture - The orientation of any body segment relative to the gravitational vector. It is an angular measure from the vertical [1]. • Balance - The dynamics of body posture that prevents falling. It is related to the inertial forces acting on the body and the inertial characteristics of body segments [1]. • Center of Mass (COM) - A specific point at which the system's mass behaves as if it were concentrated [1]. • Center of Pressure (COP) - The point location of the vertical ground reaction force vector. It represents a weighted average of all the pressures over the surface of the area that is in contact with the ground. It is also called the Center of Balance (COB) [1]. 2. 3. 3 Software • Therapy - A series of tasks that is completed in one session. • Session - A given time in which a user completes a therapy. • Task - A subunit of a therapy that has an objective with success and fail criteria.

Senior Design – Requirements Specification Review INDEX / TABLE OF CONTENTS Team Inversion Software

Senior Design – Requirements Specification Review INDEX / TABLE OF CONTENTS Team Inversion Software Requirements Specification 1 By Angry Face Studios 1 1 Introduction 4 1. 1 Scope 4 1. 2 Purpose 4 1. 3 Definitions, Acronyms, and Abbreviations 1. 4 Overview 5 2 Overall Description 5 2. 1 Product Perspective 5 2. 2 Game Play Concepts 6 2. 2. 1 Game Modes 6 2. 2. 2 Items 8 2. 3 Product Functions 9 2. 3. 1 Agent 9 2. 3. 2 Operator 9 2. 3. 3 Server 10 2. 4 System Interface 10 2. 5 User Interface 10 4