Senior Design – Requirements Specification Review REQUIREMENTS SPECIFICATION The goal is to specify: what is to be accomplished how the system or product.

Senior Design – Requirements Specification ReviewSenior Design – Requirements Specification Review

REQUIREMENTS SPECIFICATIONREQUIREMENTS SPECIFICATION

The goal is to specify:The goal is to specify:

what is to be accomplishedwhat is to be accomplished how the system or product fits into the needs of the businesshow the system or product fits into the needs of the business how the system is to be used on a day-to-day basishow the system is to be used on a day-to-day basis

Sounds simple, reality is it is quite difficult.Sounds simple, reality is it is quite difficult.

Specification can mean different things to different people.Specification can mean different things to different people.

A specification can be written as: A specification can be written as:

a written documenta written document a set of graphical modelsa set of graphical models a formal mathematical modela formal mathematical model a collection of usage scenariosa collection of usage scenarios a prototypea prototype any combination of these.any combination of these.

We use a combination of these.We use a combination of these.

REQUIREMENTS DOCUMENT STRUCTUREREQUIREMENTS DOCUMENT STRUCTURE

Introduction (Requirements Definition)Introduction (Requirements Definition)– Describe need for the system and how it fits with business objectives.Describe need for the system and how it fits with business objectives.

Functional RequirementsFunctional Requirements– Describe the services to be provided in detail. May include, use cases, state Describe the services to be provided in detail. May include, use cases, state

diagrams, and other graphical representations.diagrams, and other graphical representations.

Non-functional Requirements Non-functional Requirements – Define constraints on the system and the development process.Define constraints on the system and the development process.

System EvolutionSystem Evolution– Define fundamental assumptions on which the system is based and anticipated Define fundamental assumptions on which the system is based and anticipated

changes.changes.

GlossaryGlossary– Define technical terms used.Define technical terms used.

Index / Table of ContentsIndex / Table of Contents


REQUIREMENTS DEFINITONREQUIREMENTS 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.


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.



Requirements may be Requirements may be functionalfunctional or or non-functionalnon-functional

Functional requirementsFunctional requirements describe system services or features. describe system services or features.

The key is to remember it is about the The key is to remember it is about the WHATWHAT not the not the HOWHOW of your project. of your project.

One exception to this, IMHO, is the user interface. I prefer to see most of it dictated in 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 the requirements document, because it is a great tool to help the end-user understand what you are developing.what you are developing.


Functional Requirement Examples (Future Tense)Functional Requirement Examples (Future Tense)

r3.1 The software shall keep a persistent set of menus at the top of the Therapy/Profile window. r3.1 The software shall keep a persistent set of menus at the top of the Therapy/Profile window. Priority 1Priority 1

r3.2 The software shall list the menu options as text horizontally across the top of the window. r3.2 The software shall list the menu options as text horizontally across the top of the window. Priority 1Priority 1

r3.3 File Menur3.3 File Menu

r3.3.1 The software r3.3.1 The software shall display shall display a drop down menu when the \File" menu is clicked on. Priority 1a drop down menu when the \File" menu is clicked on. Priority 1

r3.3.2 The software r3.3.2 The software shall have shall have an \Import Therapies..." option in the File menu. Priority 1an \Import Therapies..." option in the File menu. Priority 1

r3.3.3 The software r3.3.3 The software shall have shall have an \Export Therapies..." option in the File menu. Priority 1an \Export Therapies..." option in the File menu. Priority 1

r3.3.4 The software r3.3.4 The software shall have shall have an \Import Profiles..." option in the File menu. Priority 1an \Import Profiles..." option in the File menu. Priority 1

r3.3.5 The software r3.3.5 The software shall have shall have an \Export Profiles..." option in the File menu. Priority 1an \Export Profiles..." option in the File menu. Priority 1

r3.3.6 The software r3.3.6 The software shall bring shall bring up the appropriate import or export dialog if any of the Import or up the appropriate import or export dialog if any of the Import or Export menu options is clicked on (see [4.3.6]). Priority 1Export menu options is clicked on (see [4.3.6]). Priority 1

r3.3.7 The software r3.3.7 The software shall have shall have a \Quit" option in the File menu. Priority 1a \Quit" option in the File menu. Priority 1

r3.3.8 The software r3.3.8 The software shall exit shall exit the program if the \Quit" option is clicked by the user. Priority 1the program if the \Quit" option is clicked by the user. Priority 1


Functional Requirement Examples (Present Tense)Functional Requirement Examples (Present Tense)

r3.1 The software r3.1 The software keepskeeps a persistent set of menus at the top of the Therapy/Profile window. Priority a persistent set of menus at the top of the Therapy/Profile window. Priority 11

r3.2 The software r3.2 The software listslists the menu options as text horizontally across the top of the window. Priority the menu options as text horizontally across the top of the window. Priority 11

r3.3 File Menur3.3 File Menu

r3.3.1 The software r3.3.1 The software displaysdisplays a drop down menu when the \File" menu is clicked on. Priority 1 a drop down menu when the \File" menu is clicked on. Priority 1

r3.3.2 The software r3.3.2 The software hashas an \Import Therapies..." option in the File menu. Priority 1 an \Import Therapies..." option in the File menu. Priority 1

r3.3.3 The software r3.3.3 The software hashas an \Export Therapies..." option in the File menu. Priority 1 an \Export Therapies..." option in the File menu. Priority 1

r3.3.4 The software r3.3.4 The software has has an \Import Profiles..." option in the File menu. Priority 1an \Import Profiles..." option in the File menu. Priority 1

r3.3.5 The software r3.3.5 The software has has an \Export Profiles..." option in the File menu. Priority 1an \Export Profiles..." option in the File menu. Priority 1

r3.3.6 The software r3.3.6 The software bringsbrings up the appropriate import or export dialog if any of the Import or Export up the appropriate import or export dialog if any of the Import or Export menu options is clicked on (see [4.3.6]). Priority 1menu options is clicked on (see [4.3.6]). Priority 1

r3.3.7 The software r3.3.7 The software hashas a \Quit" option in the File menu. Priority 1 a \Quit" option in the File menu. Priority 1

r3.3.8 The software r3.3.8 The software exitsexits the program if the \Quit" option is clicked by the user. Priority 1 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 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 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 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.be used most is potentially after development, I would write it in the active voice as above.


Functional Requirement Examples (Priorities)Functional Requirement Examples (Priorities)

Priority Level Description

Priority 1 Essential and required functionality

Priority 2 Desirable functionality

Priority 3 Extra features

REQUIREMENTS VERIFIABILITYREQUIREMENTS VERIFIABILITY

Requirements should be written so that they can be verified objectively.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 The problem with this requirement is its use of vague terms such as “errors shall be minimized”minimized”– The system should be easy to use by experienced controllers and should be The system should be easy to use by experienced controllers and should be

organized in such a way that user errors are minimized.organized in such a way that user errors are minimized.

The error rate should be been quantified.The error rate should be been quantified.

– Experienced controllers should be able to use all the system functions after a 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 total of two hours training. After this training, the average number of errors made by experienced users should not exceed two per day.made by experienced users should not exceed two per day.


Software Engineering – Requirements EngineeringSoftware Engineering – Requirements Engineering

Property Measure

Speed Processed Transactions/SecondUser/Event Response TimeScreen Refresh Time

Size K BytesNumber of RAM Chips

Ease of Use Training TimeNumber of Help Frames

Reliability Mean Time to FailureProbability of UnavailabilityRate of Failure OccurrenceAvailability

Robustness Time to Restart After FailurePercentage of Events Causing FailureProbability of Data Corruption on Failure

Portability Percentage of Target Dependent StatementsNumber of Target Systems

REQUIREMENTS VERIFIABILITYREQUIREMENTS VERIFIABILITY

USE CASESUSE CASES

It is helpful to create scenarios that identify a thread of usage for the system to be It is helpful to create scenarios that identify a thread of usage for the system to be constructed.constructed.

These scenarios are often called These scenarios are often called use casesuse cases..

Use cases tell a story about how an end user interacts with the system under a specific Use cases tell a story about how an end user interacts with the system under a specific set of circumstances. set of circumstances.

This story may be:This story may be:

narrative textnarrative text an outline of tasks or interactionsan outline of tasks or interactions a template-based descriptiona template-based description diagrammatic representationdiagrammatic representation

It depicts software from an end-user point of view.It depicts software from an end-user point of view.



DEVELOPING USE CASESDEVELOPING USE CASES

““A use case captures a contract.. [that] describes the system’s behavior under various 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 conditions as the system’s behavior under various conditions as the system responds to a request from one of its stakeholders.”a request from one of its stakeholders.”

Steps in creating a use case:Steps in creating a use case:

Step One:Step One: Define the actors that will be in involved in the story.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 Actors are different people (or devices) that use the system or product within the context of the function/behavior that is to be described.context of the function/behavior that is to be described.

Actors represent the roles that people (or devices) play as the system operates.Actors represent the roles that people (or devices) play as the system operates.

An actor is anything that communicates with the system or product.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 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.may play many roles. An actor plays one role in the context of a use-case.



Questions to ask about actors:Questions to ask about actors:

Who are the actor(s)?Who are the actor(s)? What are the actor’s goals?What are the actor’s goals? What preconditions should exist before the story begins?What preconditions should exist before the story begins? What exceptions might be considered as the story is described?What exceptions might be considered as the story is described? What variations in the actor’s interaction are possible?What variations in the actor’s interaction are possible? What type of system information will the actor acquire, produce, or change?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?Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system?What information does the actor desire from the system? Does the actor wish to be informed about unexpected change?Does the actor wish to be informed about unexpected change?



Think about a home security system. Think about a home security system.



Think about a home security system. Think about a home security system.

Three actors exist: homeowner/configuration manager, sensors, and the monitoring Three actors exist: homeowner/configuration manager, sensors, and the monitoring subsystem.subsystem.

Let’s look at the homeowner. The homeowner interacts with the home security function 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:in a number of different ways using either the alarm control panel or a PC:

Enters a password to allow all other interactions.Enters a password to allow all other interactions. Inquires about the status of a security zone.Inquires about the status of a security zone. Inquiries about the status of a sensor. Inquiries about the status of a sensor. Presses the panic button in an emergency.Presses the panic button in an emergency. Activates/deactivate the security system.Activates/deactivate the security system.



Use case: InitiateMonitoringUse case: InitiateMonitoring

Primary Actor: HomeownerPrimary Actor: Homeowner

Goal in context: To set the system to monitor sensors when the homeowner leaves the Goal in context: To set the system to monitor sensors when the homeowner leaves the house or remains inside.house or remains inside.

Preconditions: System was programmed for a password and to recognize various Preconditions: System was programmed for a password and to recognize various sensors.sensors.

Trigger:Trigger: The homeowner decides to “set” the system, i.e turn on the alarm function.The homeowner decides to “set” the system, i.e turn on the alarm function.

Scenario:Scenario: Homeowner observes control panel.Homeowner observes control panel. Homeowner enters password.Homeowner enters password. Homeowner selects ‘stay” or “away”Homeowner selects ‘stay” or “away”Homeowner observes red alarm light to indicate that SafeHome has been armedHomeowner observes red alarm light to indicate that SafeHome has been armed



Exceptions:Exceptions:

1.1. Control panel is not ready: Homeowner checks all sensors to determine which Control panel is not ready: Homeowner checks all sensors to determine which are open and closes them.are open and closes them.

2.2. Password is incorrect (control panel beeps once) homeowner renters correct Password is incorrect (control panel beeps once) homeowner renters correct password.password.

3.3. Password not recognized: monitoring and response subsytem must be contacted Password not recognized: monitoring and response subsytem must be contacted to reprogram passwordto reprogram password

4.4. Stay is selected: control panel beeps twice and a stay light is lit; perimeter Stay is selected: control panel beeps twice and a stay light is lit; perimeter sensors are activatedsensors are activated

5.5. Away is selected. Control panel beeps three times and an away light is lit; all Away is selected. Control panel beeps three times and an away light is lit; all sensors are activatedsensors are activated

Priority: Essential, must be implementedPriority: Essential, must be implemented

When available: First IncrementWhen available: First Increment

Frequency of use: Many times a dayFrequency of use: Many times a day

Channel to actor: via control panelChannel to actor: via control panel



Secondary Actors: support technician, sensors.Secondary Actors: support technician, sensors.

Open issues:Open issues:

1.1. Should there be a way to activate the system without the use of a password or Should there be a way to activate the system without the use of a password or with an abbreviated password?with an abbreviated password?

2.2. Should the control panel display additional text messages?Should the control panel display additional text messages?

3.3. Ho w much time does the homeowner have to enter a password from the time Ho w much time does the homeowner have to enter a password from the time the first key is pressed?the first key is pressed?

4.4. Is there a way to deactivate the system before it activates?Is there a way to deactivate the system before it activates?





Are use cases always helpful?Are use cases always helpful?

I am a strong believer that use cases that do not add to the understanding of a project 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 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: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?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 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. valuable. See how the Intelligent Tactical Mesh Networks project used use cases.

http://www.youtube.com/watch?v=pfYs5C8D4uk



First, they defined the symbols used.First, they defined the symbols used.



Symbols continued:Symbols continued:



First Use Case:First Use Case:









Another Use Case:Another Use Case:








DOCUMENTING THE USER INTERFACEDOCUMENTING THE USER INTERFACE

Example Global Basketball Network:Example Global Basketball Network:

Create a new posting for the Ecommerce SystemCreate a new posting for the Ecommerce System

RequirementsRequirements

4.5.2.1 - A textbox for the posting’s title. This is limited to 80 plaintext characters.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 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.user may enter a range of values in any currency.

4.5.2.3 - The price is optional and may be left blank.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 A4.5.2.4 – A textbox for the zip code location of the item. This is limited to 5 numerical characters.characters.

4.5.2.5 - A combo box for the user to select the category.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.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.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 4.5.2.8 A text area for the description of the item. This is limited to 1024 plaintext characters.characters.

..

..

..


DOCUMENTING THE USER INTERFACEDOCUMENTING THE USER INTERFACE

Example Global Basketball Network:Example Global Basketball Network:

Software Engineering – Analysis ModelingSoftware Engineering – Analysis Modeling

SCENARIO BASED-MODELINGSCENARIO 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 ModelingSoftware Engineering – Analysis Modeling

SCENARIO BASED-MODELINGSCENARIO 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.


SCENARIO BASED MODELINGSCENARIO BASED MODELING

ACTIVITY DIAGRAM ACTIVITY DIAGRAM

Demonstrating how the Demonstrating how the

system will worksystem will work


Formal SpecificationFormal Specification

function Search ( X: array 1 .. N of INTEGER; Key: INTEGER )function Search ( X: array 1 .. N of INTEGER; Key: INTEGER ) return INTEGER ; return INTEGER ;

Pre: Pre: 1 1 iiN N X[i] = KeyX[i] = Key

Post: X’ [Search (X, Key)] = Key Post: X’ [Search (X, Key)] = Key X = X’ X = X’ Key’ = KeyKey’ = Key


Non-functional requirementsNon-functional requirements is a constraint on the system or on the development is a constraint on the system or on the development process. This may include some description of the HOW.process. This may include some description of the HOW.

Non-functional requirements may include:Non-functional requirements may include:

security standardssecurity standards system properties and constraints e.g., reliability, response time and storage system properties and constraints e.g., reliability, response time and storage

requirements. Constraints are I/O device capability, system representations, etc.requirements. Constraints are I/O device capability, system representations, etc. process requirements may also be specified mandating a particular CASE process requirements may also be specified mandating a particular CASE

system, programming language or development method.system, programming language or development method.

Non-functional requirements may be more critical than functional requirements. If Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.these are not met, the system is useless.


NON FUNCTIONAL REQUIREMENTS – EXAMPLESNON FUNCTIONAL REQUIREMENTS – EXAMPLES

4.6.1 Software Constraints4.6.1 Software Constraints• The software will rely on the Microsoft .Net Framework. It is assumed that any system running this 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.software has the Microsoft .Net 2.0 or greater correctly installed.• All drivers must be installed and configured for the Bluetooth USB receiver(s).All drivers must be installed and configured for the Bluetooth USB receiver(s).

4.6.2 Hardware Constraints4.6.2 Hardware Constraints• Minimum of one available USB slotMinimum of one available USB slot• One Bluetooth USB per Wii input deviceOne Bluetooth USB per Wii input device• Keyboard and mouseKeyboard and mouse• Monitor or other video display deviceMonitor or other video display device• 100MB hard disk space100MB hard disk space• 256MB available memory256MB available memory• 1GHz processor1GHz processor• 64MB video card64MB video card

4.6.3 Acceptance Constraints4.6.3 Acceptance Constraints• Before accepting the system, the developers must complete the following:Before accepting the system, the developers must complete the following:• Demo the working system and any features upon request.Demo the working system and any features upon request.• Prove that all Priority 1 functional requirements are met.Prove that all Priority 1 functional requirements are met.• Provide sufficient test cases to show that the system is complete and correct.Provide sufficient test cases to show that the system is complete and correct.

VALIDATIONVALIDATION

How do you Validate that you’ve done a good job?How do you Validate that you’ve done a good job?

You might think that quality is hard to quantify during requirements engineering. After 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?all, how can you determine if what the end-user/customer is telling you is correct?

However you can check for:However you can check for:

ambiguityambiguity conflictsconflicts omissions (some, obviously not all)omissions (some, obviously not all)


TRACEABILITYTRACEABILITY

Every requirement is given a unique identifier. This helps with traceability.Every requirement is given a unique identifier. This helps with traceability.

You can include any of the following diagrams:You can include any of the following diagrams:

Source traceability table: identifies the source of each requirementSource traceability table: identifies the source of each requirement Dependency traceability table: identifies how requirements are related to Dependency traceability table: identifies how requirements are related to

anotheranother Subsystem traceability table: Categorizes requirements by the subsystems they Subsystem traceability table: Categorizes requirements by the subsystems they

govern.govern. Interface traceability table: relates requirements to both internal and external Interface traceability table: relates requirements to both internal and external

interfaces.interfaces.



BUILDING THE ANALYSIS MODELBUILDING THE ANALYSIS MODEL

An analysis model provides a description of the required information, functional , and An analysis model provides a description of the required information, functional , and behavioral domains for a computer based system.behavioral domains for a computer based system.

An analysis model will change during the requirements gathering with some areas An analysis model will change during the requirements gathering with some areas stable and others being volatile. stable and others being volatile.

There are many ways to represent the model.There are many ways to represent the model.

Scenario-based elements: The system is described from the user’s point of view.Scenario-based elements: The system is described from the user’s point of view.

GLOSSARYGLOSSARY

List any definitions, acronyms or abbreviations used within your document.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.


INDEX / TABLE OF CONTENTSINDEX / TABLE OF CONTENTS

Team InversionTeam Inversion

Software Requirements SpecificationSoftware Requirements Specification 11

By Angry Face StudiosBy Angry Face Studios 11

1 Introduction1 Introduction 44

1.11.1ScopeScope 44

1.2 1.2 PurposePurpose 44

1.3 1.3 Definitions, Acronyms, and AbbreviationsDefinitions, Acronyms, and Abbreviations 44

1.4 1.4 OverviewOverview 55

2 Overall Description2 Overall Description 55

2.1 Product Perspective2.1 Product Perspective 55

2.2 Game Play Concepts2.2 Game Play Concepts 66

2.2.1 Game Modes2.2.1 Game Modes 66

2.2.2 Items2.2.2 Items 88

2.3 Product Functions2.3 Product Functions 99

2.3.1 Agent2.3.1 Agent 99

2.3.2 Operator2.3.2 Operator 99

2.3.3 Server2.3.3 Server1010

2.4 System Interface2.4 System Interface 1010

2.5 User Interface2.5 User Interface 1010


Senior Design – Requirements Specification Review REQUIREMENTS SPECIFICATION The goal is to specify: what is to be accomplished how the system or product.

Documents

nonfunctional requirements

requirements definiton

system services

system evolution

written document

based therapy

software sh

motionbased controls