1 / 41

Senior Design – Requirements Specification Review

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

lynnea
Télécharger la présentation

Senior Design – Requirements Specification Review

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Senior Design – Requirements Specification Review REQUIREMENTS SPECIFICATION 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 Specification 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 / Table of Contents

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

  5. 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.

  6. Senior Design – Requirements Specification Review Functional Requirement Examples (Future Tense) r3.1 The software shall keep a persistent set of menus at the top of the Therapy/Profile 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

  7. Senior Design – Requirements Specification Review Functional Requirement Examples (Present Tense) r3.1 The software keeps a persistent set of menus at the top of the Therapy/Profile window. Priority 1 r3.2 The software lists the menu options as text horizontally across the top of the window. Priority 1 r3.3 File Menu r3.3.1 The software displays a drop down menu when the \File" menu is clicked on. Priority 1 r3.3.2 The software has an \Import Therapies..." option in the File menu. Priority 1 r3.3.3 The software has an \Export Therapies..." option in the File menu. Priority 1 r3.3.4 The software has an \Import Profiles..." option in the File menu. Priority 1 r3.3.5 The software has an \Export Profiles..." option in the File menu. Priority 1 r3.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 r3.3.7 The software has a \Quit" option in the File menu. Priority 1 r3.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.

  8. Senior Design – Requirements Specification Review Functional Requirement Examples (Priorities)

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

  10. Software Engineering – Requirements Engineering REQUIREMENTS VERIFIABILITY

  11. 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: narrative text an outline of tasks or interactions a template-based description diagrammatic representation It depicts software from an end-user point of view.

  12. 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.

  13. 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?

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

  15. 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.

  16. 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

  17. 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

  18. 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?

  19. Software Engineering – Requirements Engineering DEVELOPING USE CASES

  20. 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=pfYs5C8D4uk 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.

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

  22. Software Engineering – Requirements Engineering DEVELOPING USE CASES Symbols continued:

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

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

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

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

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

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

  29. 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. A4.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. . . .

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

  31. 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

  32. 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 – Analysis Modeling SCENARIO BASED-MODELING

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

  34. 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

  35. 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.

  36. 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 100MB hard disk space 256MB available memory 1GHz processor 64MB 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.

  37. 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: ambiguity conflicts omissions (some, obviously not all)

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

  39. 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.

  40. 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.

  41. 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 4 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

More Related