32
Requirement Engineering (Adapted from Dr. Osman Balci) Sung Hee Park Department of Mathematics and Computer Science Virginia State University August 23, 2012
| Date post: | 26-Dec-2015 |
| Category: |
Documents |
| Upload: | rosalind-curtis |
| View: | 222 times |
| Download: | 0 times |
Requirement Engineering(Adapted from Dr Osman Balci)
Sung Hee Park
Department of Mathematics and Computer Science
Virginia State University
August 23 2012
A Requirements Engineering Life Cycle
Problem Formulation Analyze the problem domain Identify the community of interest Identify the stakeholders decision makers
customers and potential users who will benefit from the solution to be provided andor has control or influence on the solution
Gather data and information about the problem domain within the established boundary
Specify the needs and objectives of the stakeholders decision makers customers and potential users identified
Identify and specify the constraints Specify all assumptions made clearly and
explicitly
Feasibility Assessment
Given the Formulated Problem assess the feasibility of providing a software-based solution
Can the software-based solution be provided Under a budget acceptable to upper
management sponsor or customer Within a desired period of time schedule Using the current software hardware
technology In a way to possess acceptable Interoperability
with existing (legacy) systems
Requirements Elicitationand Analysis
Customer no one knows what the ldquorealrdquo requirements must be
Develop models (representations) of the system (problem domain) to assist in elicitation of the requirements
Problems of Requirements Analysis Stakeholders donrsquot know what they really
want Stakeholders express requirements in
their own terms Different stakeholders may have
conflicting requirements Organizational and political factors may
influence the system requirements The requirements change during the
analysis process New stakeholders may emerge and the business environment may change
Quality Function Deployment (QFD) Is a quality management technique that translates the
customer needs into technical requirements for software
Concentrates on maximizing customer satisfaction Emphasizes an understanding of what is valuable to
the customer and then deploys these values throughout the engineering process
Identifies three types of requirements Normal Requirements If these requirements are present
the customer is satisfied Expected Requirements are implicit and so fundamental
that the customer does not explicitly state them
Examples accuracy ease of use ease of installation Exciting Requirements go beyond the customerrsquos
expectations and prove to be very satisfying when present
Quality Function Deployment (QFD) Concepts Function deployment determines the
ldquovaluerdquo (as perceived by the customer) of each function required of the system
Information deployment identifies data objects and events that the system must consume and produce
Task deployment examines the behavior of the system or product within the context of its environment
Value analysis determines the relative priority of requirements
Viewpoint-Oriented Elicitation Requirements are elicited from the viewpoints of
many people such as end-users managers engineers and domain experts These people are called stakeholders
For example Stakeholders for a bank Automatic Teller Machine (ATM) system may include Current bank customers Representatives from other banks Managers of bank branches Counter staff at bank branches The bankrsquos database administrators The bankrsquos security managers The bankrsquos marketing people The bankrsquos hardware and software maintenance
engineers
Viewpoint-Oriented Requirements Definition (VORD)
1048708 Viewpoint identification Discover viewpoints which receive system services and identify the services provided to each viewpoint 1048708 Viewpoint structuring Group related viewpoints into a hierarchy Common services are provided at higher-levels in the hierarchy 1048708 Viewpoint documentation Refine the description of the identified viewpoints and services 1048708 Viewpoint-system mapping Transform the analysis to an object-oriented design
Brainstorming for Viewpoint Identification
Use Cases A collection of user scenarios that describe the thread of
usage of a system Each scenario is described from the point-of-view of an
ldquoactorrdquomdasha person device or component that interacts with the software in some way
Each scenario answers the following questions Who is the primary actor the secondary actor(s) What are the actorrsquos goals What preconditions should exist before the story begins What main tasks or functions are performed by the actor What extensions might be considered as the story is described What variations in the actorrsquos interaction are possible What 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 changes
A Use-Case Diagram for a Home Security System
A Use Case Description Template 1 Use Case Name 2 Actors 3 Preconditions 4 Flow of Events of the Primary Scenario 5 Flows of Events of the Secondary
Scenarios a Alternative scenarios b Exception scenarios 6 Extension Points 7 ldquoUsedrdquo Use Cases 8 Postconditions
Requirements Identification Given a Use Case identify the functional
and non-functional requirements associated with that Use Case
Requirements are classified into two major categories Functional Requirements Non-Functional Requirements
Use Case-based Requirements Engineering is considered the Best Practice
Why is Use Case-based Requirements Engineering the Best Practice A Use Case represents a small amount of work the software
system is required to perform Thus decomposing a complex software system functionality into Use Cases enables the modularization needed to overcome the complexity
Identifying the ldquorealrdquo functional requirements is always challenging for complex software systems A Use Case describes an interaction and based on that description ldquorealrdquo functional requirements can be more successfully identified and associated with that Use Case
Listing requirements one after the other even in different categories does not provide any help for transitioning from requirements to software system design On the other hand Use Cases turn themselves into classes in an object-oriented design and significantly facilitate the transition
Associating functional requirements with a Use Case enables better traceability
requirement harr use case harr class in design harr class in code
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
A Requirements Engineering Life Cycle
Problem Formulation Analyze the problem domain Identify the community of interest Identify the stakeholders decision makers
customers and potential users who will benefit from the solution to be provided andor has control or influence on the solution
Gather data and information about the problem domain within the established boundary
Specify the needs and objectives of the stakeholders decision makers customers and potential users identified
Identify and specify the constraints Specify all assumptions made clearly and
explicitly
Feasibility Assessment
Given the Formulated Problem assess the feasibility of providing a software-based solution
Can the software-based solution be provided Under a budget acceptable to upper
management sponsor or customer Within a desired period of time schedule Using the current software hardware
technology In a way to possess acceptable Interoperability
with existing (legacy) systems
Requirements Elicitationand Analysis
Customer no one knows what the ldquorealrdquo requirements must be
Develop models (representations) of the system (problem domain) to assist in elicitation of the requirements
Problems of Requirements Analysis Stakeholders donrsquot know what they really
want Stakeholders express requirements in
their own terms Different stakeholders may have
conflicting requirements Organizational and political factors may
influence the system requirements The requirements change during the
analysis process New stakeholders may emerge and the business environment may change
Quality Function Deployment (QFD) Is a quality management technique that translates the
customer needs into technical requirements for software
Concentrates on maximizing customer satisfaction Emphasizes an understanding of what is valuable to
the customer and then deploys these values throughout the engineering process
Identifies three types of requirements Normal Requirements If these requirements are present
the customer is satisfied Expected Requirements are implicit and so fundamental
that the customer does not explicitly state them
Examples accuracy ease of use ease of installation Exciting Requirements go beyond the customerrsquos
expectations and prove to be very satisfying when present
Quality Function Deployment (QFD) Concepts Function deployment determines the
ldquovaluerdquo (as perceived by the customer) of each function required of the system
Information deployment identifies data objects and events that the system must consume and produce
Task deployment examines the behavior of the system or product within the context of its environment
Value analysis determines the relative priority of requirements
Viewpoint-Oriented Elicitation Requirements are elicited from the viewpoints of
many people such as end-users managers engineers and domain experts These people are called stakeholders
For example Stakeholders for a bank Automatic Teller Machine (ATM) system may include Current bank customers Representatives from other banks Managers of bank branches Counter staff at bank branches The bankrsquos database administrators The bankrsquos security managers The bankrsquos marketing people The bankrsquos hardware and software maintenance
engineers
Viewpoint-Oriented Requirements Definition (VORD)
1048708 Viewpoint identification Discover viewpoints which receive system services and identify the services provided to each viewpoint 1048708 Viewpoint structuring Group related viewpoints into a hierarchy Common services are provided at higher-levels in the hierarchy 1048708 Viewpoint documentation Refine the description of the identified viewpoints and services 1048708 Viewpoint-system mapping Transform the analysis to an object-oriented design
Brainstorming for Viewpoint Identification
Use Cases A collection of user scenarios that describe the thread of
usage of a system Each scenario is described from the point-of-view of an
ldquoactorrdquomdasha person device or component that interacts with the software in some way
Each scenario answers the following questions Who is the primary actor the secondary actor(s) What are the actorrsquos goals What preconditions should exist before the story begins What main tasks or functions are performed by the actor What extensions might be considered as the story is described What variations in the actorrsquos interaction are possible What 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 changes
A Use-Case Diagram for a Home Security System
A Use Case Description Template 1 Use Case Name 2 Actors 3 Preconditions 4 Flow of Events of the Primary Scenario 5 Flows of Events of the Secondary
Scenarios a Alternative scenarios b Exception scenarios 6 Extension Points 7 ldquoUsedrdquo Use Cases 8 Postconditions
Requirements Identification Given a Use Case identify the functional
and non-functional requirements associated with that Use Case
Requirements are classified into two major categories Functional Requirements Non-Functional Requirements
Use Case-based Requirements Engineering is considered the Best Practice
Why is Use Case-based Requirements Engineering the Best Practice A Use Case represents a small amount of work the software
system is required to perform Thus decomposing a complex software system functionality into Use Cases enables the modularization needed to overcome the complexity
Identifying the ldquorealrdquo functional requirements is always challenging for complex software systems A Use Case describes an interaction and based on that description ldquorealrdquo functional requirements can be more successfully identified and associated with that Use Case
Listing requirements one after the other even in different categories does not provide any help for transitioning from requirements to software system design On the other hand Use Cases turn themselves into classes in an object-oriented design and significantly facilitate the transition
Associating functional requirements with a Use Case enables better traceability
requirement harr use case harr class in design harr class in code
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Problem Formulation Analyze the problem domain Identify the community of interest Identify the stakeholders decision makers
customers and potential users who will benefit from the solution to be provided andor has control or influence on the solution
Gather data and information about the problem domain within the established boundary
Specify the needs and objectives of the stakeholders decision makers customers and potential users identified
Identify and specify the constraints Specify all assumptions made clearly and
explicitly
Feasibility Assessment
Given the Formulated Problem assess the feasibility of providing a software-based solution
Can the software-based solution be provided Under a budget acceptable to upper
management sponsor or customer Within a desired period of time schedule Using the current software hardware
technology In a way to possess acceptable Interoperability
with existing (legacy) systems
Requirements Elicitationand Analysis
Customer no one knows what the ldquorealrdquo requirements must be
Develop models (representations) of the system (problem domain) to assist in elicitation of the requirements
Problems of Requirements Analysis Stakeholders donrsquot know what they really
want Stakeholders express requirements in
their own terms Different stakeholders may have
conflicting requirements Organizational and political factors may
influence the system requirements The requirements change during the
analysis process New stakeholders may emerge and the business environment may change
Quality Function Deployment (QFD) Is a quality management technique that translates the
customer needs into technical requirements for software
Concentrates on maximizing customer satisfaction Emphasizes an understanding of what is valuable to
the customer and then deploys these values throughout the engineering process
Identifies three types of requirements Normal Requirements If these requirements are present
the customer is satisfied Expected Requirements are implicit and so fundamental
that the customer does not explicitly state them
Examples accuracy ease of use ease of installation Exciting Requirements go beyond the customerrsquos
expectations and prove to be very satisfying when present
Quality Function Deployment (QFD) Concepts Function deployment determines the
ldquovaluerdquo (as perceived by the customer) of each function required of the system
Information deployment identifies data objects and events that the system must consume and produce
Task deployment examines the behavior of the system or product within the context of its environment
Value analysis determines the relative priority of requirements
Viewpoint-Oriented Elicitation Requirements are elicited from the viewpoints of
many people such as end-users managers engineers and domain experts These people are called stakeholders
For example Stakeholders for a bank Automatic Teller Machine (ATM) system may include Current bank customers Representatives from other banks Managers of bank branches Counter staff at bank branches The bankrsquos database administrators The bankrsquos security managers The bankrsquos marketing people The bankrsquos hardware and software maintenance
engineers
Viewpoint-Oriented Requirements Definition (VORD)
1048708 Viewpoint identification Discover viewpoints which receive system services and identify the services provided to each viewpoint 1048708 Viewpoint structuring Group related viewpoints into a hierarchy Common services are provided at higher-levels in the hierarchy 1048708 Viewpoint documentation Refine the description of the identified viewpoints and services 1048708 Viewpoint-system mapping Transform the analysis to an object-oriented design
Brainstorming for Viewpoint Identification
Use Cases A collection of user scenarios that describe the thread of
usage of a system Each scenario is described from the point-of-view of an
ldquoactorrdquomdasha person device or component that interacts with the software in some way
Each scenario answers the following questions Who is the primary actor the secondary actor(s) What are the actorrsquos goals What preconditions should exist before the story begins What main tasks or functions are performed by the actor What extensions might be considered as the story is described What variations in the actorrsquos interaction are possible What 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 changes
A Use-Case Diagram for a Home Security System
A Use Case Description Template 1 Use Case Name 2 Actors 3 Preconditions 4 Flow of Events of the Primary Scenario 5 Flows of Events of the Secondary
Scenarios a Alternative scenarios b Exception scenarios 6 Extension Points 7 ldquoUsedrdquo Use Cases 8 Postconditions
Requirements Identification Given a Use Case identify the functional
and non-functional requirements associated with that Use Case
Requirements are classified into two major categories Functional Requirements Non-Functional Requirements
Use Case-based Requirements Engineering is considered the Best Practice
Why is Use Case-based Requirements Engineering the Best Practice A Use Case represents a small amount of work the software
system is required to perform Thus decomposing a complex software system functionality into Use Cases enables the modularization needed to overcome the complexity
Identifying the ldquorealrdquo functional requirements is always challenging for complex software systems A Use Case describes an interaction and based on that description ldquorealrdquo functional requirements can be more successfully identified and associated with that Use Case
Listing requirements one after the other even in different categories does not provide any help for transitioning from requirements to software system design On the other hand Use Cases turn themselves into classes in an object-oriented design and significantly facilitate the transition
Associating functional requirements with a Use Case enables better traceability
requirement harr use case harr class in design harr class in code
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Feasibility Assessment
Given the Formulated Problem assess the feasibility of providing a software-based solution
Can the software-based solution be provided Under a budget acceptable to upper
management sponsor or customer Within a desired period of time schedule Using the current software hardware
technology In a way to possess acceptable Interoperability
with existing (legacy) systems
Requirements Elicitationand Analysis
Customer no one knows what the ldquorealrdquo requirements must be
Develop models (representations) of the system (problem domain) to assist in elicitation of the requirements
Problems of Requirements Analysis Stakeholders donrsquot know what they really
want Stakeholders express requirements in
their own terms Different stakeholders may have
conflicting requirements Organizational and political factors may
influence the system requirements The requirements change during the
analysis process New stakeholders may emerge and the business environment may change
Quality Function Deployment (QFD) Is a quality management technique that translates the
customer needs into technical requirements for software
Concentrates on maximizing customer satisfaction Emphasizes an understanding of what is valuable to
the customer and then deploys these values throughout the engineering process
Identifies three types of requirements Normal Requirements If these requirements are present
the customer is satisfied Expected Requirements are implicit and so fundamental
that the customer does not explicitly state them
Examples accuracy ease of use ease of installation Exciting Requirements go beyond the customerrsquos
expectations and prove to be very satisfying when present
Quality Function Deployment (QFD) Concepts Function deployment determines the
ldquovaluerdquo (as perceived by the customer) of each function required of the system
Information deployment identifies data objects and events that the system must consume and produce
Task deployment examines the behavior of the system or product within the context of its environment
Value analysis determines the relative priority of requirements
Viewpoint-Oriented Elicitation Requirements are elicited from the viewpoints of
many people such as end-users managers engineers and domain experts These people are called stakeholders
For example Stakeholders for a bank Automatic Teller Machine (ATM) system may include Current bank customers Representatives from other banks Managers of bank branches Counter staff at bank branches The bankrsquos database administrators The bankrsquos security managers The bankrsquos marketing people The bankrsquos hardware and software maintenance
engineers
Viewpoint-Oriented Requirements Definition (VORD)
1048708 Viewpoint identification Discover viewpoints which receive system services and identify the services provided to each viewpoint 1048708 Viewpoint structuring Group related viewpoints into a hierarchy Common services are provided at higher-levels in the hierarchy 1048708 Viewpoint documentation Refine the description of the identified viewpoints and services 1048708 Viewpoint-system mapping Transform the analysis to an object-oriented design
Brainstorming for Viewpoint Identification
Use Cases A collection of user scenarios that describe the thread of
usage of a system Each scenario is described from the point-of-view of an
ldquoactorrdquomdasha person device or component that interacts with the software in some way
Each scenario answers the following questions Who is the primary actor the secondary actor(s) What are the actorrsquos goals What preconditions should exist before the story begins What main tasks or functions are performed by the actor What extensions might be considered as the story is described What variations in the actorrsquos interaction are possible What 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 changes
A Use-Case Diagram for a Home Security System
A Use Case Description Template 1 Use Case Name 2 Actors 3 Preconditions 4 Flow of Events of the Primary Scenario 5 Flows of Events of the Secondary
Scenarios a Alternative scenarios b Exception scenarios 6 Extension Points 7 ldquoUsedrdquo Use Cases 8 Postconditions
Requirements Identification Given a Use Case identify the functional
and non-functional requirements associated with that Use Case
Requirements are classified into two major categories Functional Requirements Non-Functional Requirements
Use Case-based Requirements Engineering is considered the Best Practice
Why is Use Case-based Requirements Engineering the Best Practice A Use Case represents a small amount of work the software
system is required to perform Thus decomposing a complex software system functionality into Use Cases enables the modularization needed to overcome the complexity
Identifying the ldquorealrdquo functional requirements is always challenging for complex software systems A Use Case describes an interaction and based on that description ldquorealrdquo functional requirements can be more successfully identified and associated with that Use Case
Listing requirements one after the other even in different categories does not provide any help for transitioning from requirements to software system design On the other hand Use Cases turn themselves into classes in an object-oriented design and significantly facilitate the transition
Associating functional requirements with a Use Case enables better traceability
requirement harr use case harr class in design harr class in code
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Requirements Elicitationand Analysis
Customer no one knows what the ldquorealrdquo requirements must be
Develop models (representations) of the system (problem domain) to assist in elicitation of the requirements
Problems of Requirements Analysis Stakeholders donrsquot know what they really
want Stakeholders express requirements in
their own terms Different stakeholders may have
conflicting requirements Organizational and political factors may
influence the system requirements The requirements change during the
analysis process New stakeholders may emerge and the business environment may change
Quality Function Deployment (QFD) Is a quality management technique that translates the
customer needs into technical requirements for software
Concentrates on maximizing customer satisfaction Emphasizes an understanding of what is valuable to
the customer and then deploys these values throughout the engineering process
Identifies three types of requirements Normal Requirements If these requirements are present
the customer is satisfied Expected Requirements are implicit and so fundamental
that the customer does not explicitly state them
Examples accuracy ease of use ease of installation Exciting Requirements go beyond the customerrsquos
expectations and prove to be very satisfying when present
Quality Function Deployment (QFD) Concepts Function deployment determines the
ldquovaluerdquo (as perceived by the customer) of each function required of the system
Information deployment identifies data objects and events that the system must consume and produce
Task deployment examines the behavior of the system or product within the context of its environment
Value analysis determines the relative priority of requirements
Viewpoint-Oriented Elicitation Requirements are elicited from the viewpoints of
many people such as end-users managers engineers and domain experts These people are called stakeholders
For example Stakeholders for a bank Automatic Teller Machine (ATM) system may include Current bank customers Representatives from other banks Managers of bank branches Counter staff at bank branches The bankrsquos database administrators The bankrsquos security managers The bankrsquos marketing people The bankrsquos hardware and software maintenance
engineers
Viewpoint-Oriented Requirements Definition (VORD)
1048708 Viewpoint identification Discover viewpoints which receive system services and identify the services provided to each viewpoint 1048708 Viewpoint structuring Group related viewpoints into a hierarchy Common services are provided at higher-levels in the hierarchy 1048708 Viewpoint documentation Refine the description of the identified viewpoints and services 1048708 Viewpoint-system mapping Transform the analysis to an object-oriented design
Brainstorming for Viewpoint Identification
Use Cases A collection of user scenarios that describe the thread of
usage of a system Each scenario is described from the point-of-view of an
ldquoactorrdquomdasha person device or component that interacts with the software in some way
Each scenario answers the following questions Who is the primary actor the secondary actor(s) What are the actorrsquos goals What preconditions should exist before the story begins What main tasks or functions are performed by the actor What extensions might be considered as the story is described What variations in the actorrsquos interaction are possible What 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 changes
A Use-Case Diagram for a Home Security System
A Use Case Description Template 1 Use Case Name 2 Actors 3 Preconditions 4 Flow of Events of the Primary Scenario 5 Flows of Events of the Secondary
Scenarios a Alternative scenarios b Exception scenarios 6 Extension Points 7 ldquoUsedrdquo Use Cases 8 Postconditions
Requirements Identification Given a Use Case identify the functional
and non-functional requirements associated with that Use Case
Requirements are classified into two major categories Functional Requirements Non-Functional Requirements
Use Case-based Requirements Engineering is considered the Best Practice
Why is Use Case-based Requirements Engineering the Best Practice A Use Case represents a small amount of work the software
system is required to perform Thus decomposing a complex software system functionality into Use Cases enables the modularization needed to overcome the complexity
Identifying the ldquorealrdquo functional requirements is always challenging for complex software systems A Use Case describes an interaction and based on that description ldquorealrdquo functional requirements can be more successfully identified and associated with that Use Case
Listing requirements one after the other even in different categories does not provide any help for transitioning from requirements to software system design On the other hand Use Cases turn themselves into classes in an object-oriented design and significantly facilitate the transition
Associating functional requirements with a Use Case enables better traceability
requirement harr use case harr class in design harr class in code
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Problems of Requirements Analysis Stakeholders donrsquot know what they really
want Stakeholders express requirements in
their own terms Different stakeholders may have
conflicting requirements Organizational and political factors may
influence the system requirements The requirements change during the
analysis process New stakeholders may emerge and the business environment may change
Quality Function Deployment (QFD) Is a quality management technique that translates the
customer needs into technical requirements for software
Concentrates on maximizing customer satisfaction Emphasizes an understanding of what is valuable to
the customer and then deploys these values throughout the engineering process
Identifies three types of requirements Normal Requirements If these requirements are present
the customer is satisfied Expected Requirements are implicit and so fundamental
that the customer does not explicitly state them
Examples accuracy ease of use ease of installation Exciting Requirements go beyond the customerrsquos
expectations and prove to be very satisfying when present
Quality Function Deployment (QFD) Concepts Function deployment determines the
ldquovaluerdquo (as perceived by the customer) of each function required of the system
Information deployment identifies data objects and events that the system must consume and produce
Task deployment examines the behavior of the system or product within the context of its environment
Value analysis determines the relative priority of requirements
Viewpoint-Oriented Elicitation Requirements are elicited from the viewpoints of
many people such as end-users managers engineers and domain experts These people are called stakeholders
For example Stakeholders for a bank Automatic Teller Machine (ATM) system may include Current bank customers Representatives from other banks Managers of bank branches Counter staff at bank branches The bankrsquos database administrators The bankrsquos security managers The bankrsquos marketing people The bankrsquos hardware and software maintenance
engineers
Viewpoint-Oriented Requirements Definition (VORD)
1048708 Viewpoint identification Discover viewpoints which receive system services and identify the services provided to each viewpoint 1048708 Viewpoint structuring Group related viewpoints into a hierarchy Common services are provided at higher-levels in the hierarchy 1048708 Viewpoint documentation Refine the description of the identified viewpoints and services 1048708 Viewpoint-system mapping Transform the analysis to an object-oriented design
Brainstorming for Viewpoint Identification
Use Cases A collection of user scenarios that describe the thread of
usage of a system Each scenario is described from the point-of-view of an
ldquoactorrdquomdasha person device or component that interacts with the software in some way
Each scenario answers the following questions Who is the primary actor the secondary actor(s) What are the actorrsquos goals What preconditions should exist before the story begins What main tasks or functions are performed by the actor What extensions might be considered as the story is described What variations in the actorrsquos interaction are possible What 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 changes
A Use-Case Diagram for a Home Security System
A Use Case Description Template 1 Use Case Name 2 Actors 3 Preconditions 4 Flow of Events of the Primary Scenario 5 Flows of Events of the Secondary
Scenarios a Alternative scenarios b Exception scenarios 6 Extension Points 7 ldquoUsedrdquo Use Cases 8 Postconditions
Requirements Identification Given a Use Case identify the functional
and non-functional requirements associated with that Use Case
Requirements are classified into two major categories Functional Requirements Non-Functional Requirements
Use Case-based Requirements Engineering is considered the Best Practice
Why is Use Case-based Requirements Engineering the Best Practice A Use Case represents a small amount of work the software
system is required to perform Thus decomposing a complex software system functionality into Use Cases enables the modularization needed to overcome the complexity
Identifying the ldquorealrdquo functional requirements is always challenging for complex software systems A Use Case describes an interaction and based on that description ldquorealrdquo functional requirements can be more successfully identified and associated with that Use Case
Listing requirements one after the other even in different categories does not provide any help for transitioning from requirements to software system design On the other hand Use Cases turn themselves into classes in an object-oriented design and significantly facilitate the transition
Associating functional requirements with a Use Case enables better traceability
requirement harr use case harr class in design harr class in code
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Quality Function Deployment (QFD) Is a quality management technique that translates the
customer needs into technical requirements for software
Concentrates on maximizing customer satisfaction Emphasizes an understanding of what is valuable to
the customer and then deploys these values throughout the engineering process
Identifies three types of requirements Normal Requirements If these requirements are present
the customer is satisfied Expected Requirements are implicit and so fundamental
that the customer does not explicitly state them
Examples accuracy ease of use ease of installation Exciting Requirements go beyond the customerrsquos
expectations and prove to be very satisfying when present
Quality Function Deployment (QFD) Concepts Function deployment determines the
ldquovaluerdquo (as perceived by the customer) of each function required of the system
Information deployment identifies data objects and events that the system must consume and produce
Task deployment examines the behavior of the system or product within the context of its environment
Value analysis determines the relative priority of requirements
Viewpoint-Oriented Elicitation Requirements are elicited from the viewpoints of
many people such as end-users managers engineers and domain experts These people are called stakeholders
For example Stakeholders for a bank Automatic Teller Machine (ATM) system may include Current bank customers Representatives from other banks Managers of bank branches Counter staff at bank branches The bankrsquos database administrators The bankrsquos security managers The bankrsquos marketing people The bankrsquos hardware and software maintenance
engineers
Viewpoint-Oriented Requirements Definition (VORD)
1048708 Viewpoint identification Discover viewpoints which receive system services and identify the services provided to each viewpoint 1048708 Viewpoint structuring Group related viewpoints into a hierarchy Common services are provided at higher-levels in the hierarchy 1048708 Viewpoint documentation Refine the description of the identified viewpoints and services 1048708 Viewpoint-system mapping Transform the analysis to an object-oriented design
Brainstorming for Viewpoint Identification
Use Cases A collection of user scenarios that describe the thread of
usage of a system Each scenario is described from the point-of-view of an
ldquoactorrdquomdasha person device or component that interacts with the software in some way
Each scenario answers the following questions Who is the primary actor the secondary actor(s) What are the actorrsquos goals What preconditions should exist before the story begins What main tasks or functions are performed by the actor What extensions might be considered as the story is described What variations in the actorrsquos interaction are possible What 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 changes
A Use-Case Diagram for a Home Security System
A Use Case Description Template 1 Use Case Name 2 Actors 3 Preconditions 4 Flow of Events of the Primary Scenario 5 Flows of Events of the Secondary
Scenarios a Alternative scenarios b Exception scenarios 6 Extension Points 7 ldquoUsedrdquo Use Cases 8 Postconditions
Requirements Identification Given a Use Case identify the functional
and non-functional requirements associated with that Use Case
Requirements are classified into two major categories Functional Requirements Non-Functional Requirements
Use Case-based Requirements Engineering is considered the Best Practice
Why is Use Case-based Requirements Engineering the Best Practice A Use Case represents a small amount of work the software
system is required to perform Thus decomposing a complex software system functionality into Use Cases enables the modularization needed to overcome the complexity
Identifying the ldquorealrdquo functional requirements is always challenging for complex software systems A Use Case describes an interaction and based on that description ldquorealrdquo functional requirements can be more successfully identified and associated with that Use Case
Listing requirements one after the other even in different categories does not provide any help for transitioning from requirements to software system design On the other hand Use Cases turn themselves into classes in an object-oriented design and significantly facilitate the transition
Associating functional requirements with a Use Case enables better traceability
requirement harr use case harr class in design harr class in code
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Quality Function Deployment (QFD) Concepts Function deployment determines the
ldquovaluerdquo (as perceived by the customer) of each function required of the system
Information deployment identifies data objects and events that the system must consume and produce
Task deployment examines the behavior of the system or product within the context of its environment
Value analysis determines the relative priority of requirements
Viewpoint-Oriented Elicitation Requirements are elicited from the viewpoints of
many people such as end-users managers engineers and domain experts These people are called stakeholders
For example Stakeholders for a bank Automatic Teller Machine (ATM) system may include Current bank customers Representatives from other banks Managers of bank branches Counter staff at bank branches The bankrsquos database administrators The bankrsquos security managers The bankrsquos marketing people The bankrsquos hardware and software maintenance
engineers
Viewpoint-Oriented Requirements Definition (VORD)
1048708 Viewpoint identification Discover viewpoints which receive system services and identify the services provided to each viewpoint 1048708 Viewpoint structuring Group related viewpoints into a hierarchy Common services are provided at higher-levels in the hierarchy 1048708 Viewpoint documentation Refine the description of the identified viewpoints and services 1048708 Viewpoint-system mapping Transform the analysis to an object-oriented design
Brainstorming for Viewpoint Identification
Use Cases A collection of user scenarios that describe the thread of
usage of a system Each scenario is described from the point-of-view of an
ldquoactorrdquomdasha person device or component that interacts with the software in some way
Each scenario answers the following questions Who is the primary actor the secondary actor(s) What are the actorrsquos goals What preconditions should exist before the story begins What main tasks or functions are performed by the actor What extensions might be considered as the story is described What variations in the actorrsquos interaction are possible What 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 changes
A Use-Case Diagram for a Home Security System
A Use Case Description Template 1 Use Case Name 2 Actors 3 Preconditions 4 Flow of Events of the Primary Scenario 5 Flows of Events of the Secondary
Scenarios a Alternative scenarios b Exception scenarios 6 Extension Points 7 ldquoUsedrdquo Use Cases 8 Postconditions
Requirements Identification Given a Use Case identify the functional
and non-functional requirements associated with that Use Case
Requirements are classified into two major categories Functional Requirements Non-Functional Requirements
Use Case-based Requirements Engineering is considered the Best Practice
Why is Use Case-based Requirements Engineering the Best Practice A Use Case represents a small amount of work the software
system is required to perform Thus decomposing a complex software system functionality into Use Cases enables the modularization needed to overcome the complexity
Identifying the ldquorealrdquo functional requirements is always challenging for complex software systems A Use Case describes an interaction and based on that description ldquorealrdquo functional requirements can be more successfully identified and associated with that Use Case
Listing requirements one after the other even in different categories does not provide any help for transitioning from requirements to software system design On the other hand Use Cases turn themselves into classes in an object-oriented design and significantly facilitate the transition
Associating functional requirements with a Use Case enables better traceability
requirement harr use case harr class in design harr class in code
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Viewpoint-Oriented Elicitation Requirements are elicited from the viewpoints of
many people such as end-users managers engineers and domain experts These people are called stakeholders
For example Stakeholders for a bank Automatic Teller Machine (ATM) system may include Current bank customers Representatives from other banks Managers of bank branches Counter staff at bank branches The bankrsquos database administrators The bankrsquos security managers The bankrsquos marketing people The bankrsquos hardware and software maintenance
engineers
Viewpoint-Oriented Requirements Definition (VORD)
1048708 Viewpoint identification Discover viewpoints which receive system services and identify the services provided to each viewpoint 1048708 Viewpoint structuring Group related viewpoints into a hierarchy Common services are provided at higher-levels in the hierarchy 1048708 Viewpoint documentation Refine the description of the identified viewpoints and services 1048708 Viewpoint-system mapping Transform the analysis to an object-oriented design
Brainstorming for Viewpoint Identification
Use Cases A collection of user scenarios that describe the thread of
usage of a system Each scenario is described from the point-of-view of an
ldquoactorrdquomdasha person device or component that interacts with the software in some way
Each scenario answers the following questions Who is the primary actor the secondary actor(s) What are the actorrsquos goals What preconditions should exist before the story begins What main tasks or functions are performed by the actor What extensions might be considered as the story is described What variations in the actorrsquos interaction are possible What 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 changes
A Use-Case Diagram for a Home Security System
A Use Case Description Template 1 Use Case Name 2 Actors 3 Preconditions 4 Flow of Events of the Primary Scenario 5 Flows of Events of the Secondary
Scenarios a Alternative scenarios b Exception scenarios 6 Extension Points 7 ldquoUsedrdquo Use Cases 8 Postconditions
Requirements Identification Given a Use Case identify the functional
and non-functional requirements associated with that Use Case
Requirements are classified into two major categories Functional Requirements Non-Functional Requirements
Use Case-based Requirements Engineering is considered the Best Practice
Why is Use Case-based Requirements Engineering the Best Practice A Use Case represents a small amount of work the software
system is required to perform Thus decomposing a complex software system functionality into Use Cases enables the modularization needed to overcome the complexity
Identifying the ldquorealrdquo functional requirements is always challenging for complex software systems A Use Case describes an interaction and based on that description ldquorealrdquo functional requirements can be more successfully identified and associated with that Use Case
Listing requirements one after the other even in different categories does not provide any help for transitioning from requirements to software system design On the other hand Use Cases turn themselves into classes in an object-oriented design and significantly facilitate the transition
Associating functional requirements with a Use Case enables better traceability
requirement harr use case harr class in design harr class in code
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Viewpoint-Oriented Requirements Definition (VORD)
1048708 Viewpoint identification Discover viewpoints which receive system services and identify the services provided to each viewpoint 1048708 Viewpoint structuring Group related viewpoints into a hierarchy Common services are provided at higher-levels in the hierarchy 1048708 Viewpoint documentation Refine the description of the identified viewpoints and services 1048708 Viewpoint-system mapping Transform the analysis to an object-oriented design
Brainstorming for Viewpoint Identification
Use Cases A collection of user scenarios that describe the thread of
usage of a system Each scenario is described from the point-of-view of an
ldquoactorrdquomdasha person device or component that interacts with the software in some way
Each scenario answers the following questions Who is the primary actor the secondary actor(s) What are the actorrsquos goals What preconditions should exist before the story begins What main tasks or functions are performed by the actor What extensions might be considered as the story is described What variations in the actorrsquos interaction are possible What 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 changes
A Use-Case Diagram for a Home Security System
A Use Case Description Template 1 Use Case Name 2 Actors 3 Preconditions 4 Flow of Events of the Primary Scenario 5 Flows of Events of the Secondary
Scenarios a Alternative scenarios b Exception scenarios 6 Extension Points 7 ldquoUsedrdquo Use Cases 8 Postconditions
Requirements Identification Given a Use Case identify the functional
and non-functional requirements associated with that Use Case
Requirements are classified into two major categories Functional Requirements Non-Functional Requirements
Use Case-based Requirements Engineering is considered the Best Practice
Why is Use Case-based Requirements Engineering the Best Practice A Use Case represents a small amount of work the software
system is required to perform Thus decomposing a complex software system functionality into Use Cases enables the modularization needed to overcome the complexity
Identifying the ldquorealrdquo functional requirements is always challenging for complex software systems A Use Case describes an interaction and based on that description ldquorealrdquo functional requirements can be more successfully identified and associated with that Use Case
Listing requirements one after the other even in different categories does not provide any help for transitioning from requirements to software system design On the other hand Use Cases turn themselves into classes in an object-oriented design and significantly facilitate the transition
Associating functional requirements with a Use Case enables better traceability
requirement harr use case harr class in design harr class in code
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Brainstorming for Viewpoint Identification
Use Cases A collection of user scenarios that describe the thread of
usage of a system Each scenario is described from the point-of-view of an
ldquoactorrdquomdasha person device or component that interacts with the software in some way
Each scenario answers the following questions Who is the primary actor the secondary actor(s) What are the actorrsquos goals What preconditions should exist before the story begins What main tasks or functions are performed by the actor What extensions might be considered as the story is described What variations in the actorrsquos interaction are possible What 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 changes
A Use-Case Diagram for a Home Security System
A Use Case Description Template 1 Use Case Name 2 Actors 3 Preconditions 4 Flow of Events of the Primary Scenario 5 Flows of Events of the Secondary
Scenarios a Alternative scenarios b Exception scenarios 6 Extension Points 7 ldquoUsedrdquo Use Cases 8 Postconditions
Requirements Identification Given a Use Case identify the functional
and non-functional requirements associated with that Use Case
Requirements are classified into two major categories Functional Requirements Non-Functional Requirements
Use Case-based Requirements Engineering is considered the Best Practice
Why is Use Case-based Requirements Engineering the Best Practice A Use Case represents a small amount of work the software
system is required to perform Thus decomposing a complex software system functionality into Use Cases enables the modularization needed to overcome the complexity
Identifying the ldquorealrdquo functional requirements is always challenging for complex software systems A Use Case describes an interaction and based on that description ldquorealrdquo functional requirements can be more successfully identified and associated with that Use Case
Listing requirements one after the other even in different categories does not provide any help for transitioning from requirements to software system design On the other hand Use Cases turn themselves into classes in an object-oriented design and significantly facilitate the transition
Associating functional requirements with a Use Case enables better traceability
requirement harr use case harr class in design harr class in code
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Use Cases A collection of user scenarios that describe the thread of
usage of a system Each scenario is described from the point-of-view of an
ldquoactorrdquomdasha person device or component that interacts with the software in some way
Each scenario answers the following questions Who is the primary actor the secondary actor(s) What are the actorrsquos goals What preconditions should exist before the story begins What main tasks or functions are performed by the actor What extensions might be considered as the story is described What variations in the actorrsquos interaction are possible What 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 changes
A Use-Case Diagram for a Home Security System
A Use Case Description Template 1 Use Case Name 2 Actors 3 Preconditions 4 Flow of Events of the Primary Scenario 5 Flows of Events of the Secondary
Scenarios a Alternative scenarios b Exception scenarios 6 Extension Points 7 ldquoUsedrdquo Use Cases 8 Postconditions
Requirements Identification Given a Use Case identify the functional
and non-functional requirements associated with that Use Case
Requirements are classified into two major categories Functional Requirements Non-Functional Requirements
Use Case-based Requirements Engineering is considered the Best Practice
Why is Use Case-based Requirements Engineering the Best Practice A Use Case represents a small amount of work the software
system is required to perform Thus decomposing a complex software system functionality into Use Cases enables the modularization needed to overcome the complexity
Identifying the ldquorealrdquo functional requirements is always challenging for complex software systems A Use Case describes an interaction and based on that description ldquorealrdquo functional requirements can be more successfully identified and associated with that Use Case
Listing requirements one after the other even in different categories does not provide any help for transitioning from requirements to software system design On the other hand Use Cases turn themselves into classes in an object-oriented design and significantly facilitate the transition
Associating functional requirements with a Use Case enables better traceability
requirement harr use case harr class in design harr class in code
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
A Use-Case Diagram for a Home Security System
A Use Case Description Template 1 Use Case Name 2 Actors 3 Preconditions 4 Flow of Events of the Primary Scenario 5 Flows of Events of the Secondary
Scenarios a Alternative scenarios b Exception scenarios 6 Extension Points 7 ldquoUsedrdquo Use Cases 8 Postconditions
Requirements Identification Given a Use Case identify the functional
and non-functional requirements associated with that Use Case
Requirements are classified into two major categories Functional Requirements Non-Functional Requirements
Use Case-based Requirements Engineering is considered the Best Practice
Why is Use Case-based Requirements Engineering the Best Practice A Use Case represents a small amount of work the software
system is required to perform Thus decomposing a complex software system functionality into Use Cases enables the modularization needed to overcome the complexity
Identifying the ldquorealrdquo functional requirements is always challenging for complex software systems A Use Case describes an interaction and based on that description ldquorealrdquo functional requirements can be more successfully identified and associated with that Use Case
Listing requirements one after the other even in different categories does not provide any help for transitioning from requirements to software system design On the other hand Use Cases turn themselves into classes in an object-oriented design and significantly facilitate the transition
Associating functional requirements with a Use Case enables better traceability
requirement harr use case harr class in design harr class in code
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
A Use Case Description Template 1 Use Case Name 2 Actors 3 Preconditions 4 Flow of Events of the Primary Scenario 5 Flows of Events of the Secondary
Scenarios a Alternative scenarios b Exception scenarios 6 Extension Points 7 ldquoUsedrdquo Use Cases 8 Postconditions
Requirements Identification Given a Use Case identify the functional
and non-functional requirements associated with that Use Case
Requirements are classified into two major categories Functional Requirements Non-Functional Requirements
Use Case-based Requirements Engineering is considered the Best Practice
Why is Use Case-based Requirements Engineering the Best Practice A Use Case represents a small amount of work the software
system is required to perform Thus decomposing a complex software system functionality into Use Cases enables the modularization needed to overcome the complexity
Identifying the ldquorealrdquo functional requirements is always challenging for complex software systems A Use Case describes an interaction and based on that description ldquorealrdquo functional requirements can be more successfully identified and associated with that Use Case
Listing requirements one after the other even in different categories does not provide any help for transitioning from requirements to software system design On the other hand Use Cases turn themselves into classes in an object-oriented design and significantly facilitate the transition
Associating functional requirements with a Use Case enables better traceability
requirement harr use case harr class in design harr class in code
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Requirements Identification Given a Use Case identify the functional
and non-functional requirements associated with that Use Case
Requirements are classified into two major categories Functional Requirements Non-Functional Requirements
Use Case-based Requirements Engineering is considered the Best Practice
Why is Use Case-based Requirements Engineering the Best Practice A Use Case represents a small amount of work the software
system is required to perform Thus decomposing a complex software system functionality into Use Cases enables the modularization needed to overcome the complexity
Identifying the ldquorealrdquo functional requirements is always challenging for complex software systems A Use Case describes an interaction and based on that description ldquorealrdquo functional requirements can be more successfully identified and associated with that Use Case
Listing requirements one after the other even in different categories does not provide any help for transitioning from requirements to software system design On the other hand Use Cases turn themselves into classes in an object-oriented design and significantly facilitate the transition
Associating functional requirements with a Use Case enables better traceability
requirement harr use case harr class in design harr class in code
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Why is Use Case-based Requirements Engineering the Best Practice A Use Case represents a small amount of work the software
system is required to perform Thus decomposing a complex software system functionality into Use Cases enables the modularization needed to overcome the complexity
Identifying the ldquorealrdquo functional requirements is always challenging for complex software systems A Use Case describes an interaction and based on that description ldquorealrdquo functional requirements can be more successfully identified and associated with that Use Case
Listing requirements one after the other even in different categories does not provide any help for transitioning from requirements to software system design On the other hand Use Cases turn themselves into classes in an object-oriented design and significantly facilitate the transition
Associating functional requirements with a Use Case enables better traceability
requirement harr use case harr class in design harr class in code
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Functional and Non-functional Requirements Functional requirements
Are statements of services that the software software product or software-based system should provide how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Are requirements about the behavior and input-output
transformations of the software software product or software-based system
Non-functional requirements Are requirements that are unrelated to functionality of
the software software product or software-based system
Examples Requirements for Interoperability Performance Usability Standards Delivery
Portability Privacy Safety
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Requirements Specification
In the process of Requirements Specification we technically establish each requirement identified in the previous process in a written form
By executing this process we produce the Requirements Specification Document (RSD) which is often part of the legal contract signed between the sponsor and software developer
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Specification of a Requirement A requirement is specified using ldquoshallrdquo
Example ldquoThe software system shall enable the user to specify the shipping method for the ordered productsrdquo
A requirement is engineered as a product with required quality characteristics
A requirement must not be viewed as an English language sentence
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Example Bad Requirements1048708 ldquoThe user of the software system shall beauthenticated with a username and passwordrdquo1048708 ldquoThe software system shall be very easy to
userdquo1048708 ldquoAll software system components shall
exchangedata with each otherrdquo1048708 ldquoThe software system shall provide appropriateviewers for the user to read tutorial documentsrdquo1048708 ldquoUsers shall be able to use the software systemover the Internetrdquo
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Example Functional Requirements1048708 ldquoThe user of the software system shall be authenticated with ausername and password Username shall consist of minimum 6 andmaximum 12 alphanumeric characters Password shall consist ofminimum 8 and maximum 16 characters of which at least 2 must beuppercase letters at least 2 must be lowercase letters at least 2must be numbers and at least 2 must be special charactersrdquo1048708 ldquoThe e-commerce software system shall enable the user to use alsquoshopping cartrsquo to keep track of selected items and their pricesrdquo1048708 ldquoThe user shall be able to play pause and stop the visualization atany time during the course of software executionrdquo1048708 ldquoThe e-commerce system shall enable the user to view previousorders up to one yearrdquo1048708 ldquoThe user shall be able to print an invoice for the ordered
productsrdquo1048708 ldquoThe user shall be able to create a profile that contains up to fivebilling or shipping addresses one of which shall be selectable inplacing an orderrdquo
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Example Non-Functional Requirements1048708 ldquoInteroperability among the distributed simulation softwarecomponents shall be accomplished using the High LevelArchitecture standardrdquo1048708 ldquoThe software system shall be developed using royalty-freesoftware productsrdquo1048708 ldquoThe web-based software system shall be usable with MicrosoftInternet Explorer browser version 60 or higherrdquo1048708 ldquoThe weather forecasting simulation software execution shall becompleted in no more than 6 hoursrdquo1048708 ldquoThe software system shall be executable under Sun Solaris Unixand Microsoft Windows Server 2003 operating systemsrdquo1048708 ldquoAll software documentation shall be provided in HTML-basedhypertext formatrdquo1048708 ldquoAll software input data shall be specified in XML formatrdquo
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Requirements Management1048708 Two major software products for requirementsmanagement1048708 Dynamic Object Oriented Requirements System(DOORS) ndash httpwwwtelelogiccom1048708 IBM Rational RequisitePro ndashhttpwww-306ibmcomsoftwareawdtools
reqpro1048708 ldquoOn 11 June 2007 IBM announced it will buy
Telelogic a Sweden-based provider of software development tools for enterprise life cycle management for approximately $745 million The deal is expected to close in 3Q07 Telelogic will become part of IBMlsquos Rational Software divisionrdquo
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Requirements Engineering QA1048708 Requirements Engineering Quality Assurance
(QA) integrates the assessments ofa) quality of the Requirements Specification
Document (RSD) work productb) requirements engineering process qualityc) quality of the people employed in
requirementsengineering andd) project characteristics related to the life
cycle stage for requirements engineering
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Requirements Quality Assessment
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Software Requirements Accuracyis the degree to which the requirements possess sufficienttransformational and representational correctness1048708 Software Requirements Verity is assessed by conducting
software requirements verificationSoftware requirements verification is substantiating that the
software requirements are transformed from higher levels of abstraction into their current form with sufficient accuracy Software requirements verification addresses the question of ldquoAre we creating the software requirements rightrdquo
1048708 Software Requirements Validity is assessed by conducting software requirements validation
Software requirements validation is substantiating that the software requirements represent the real needs of the customer client sponsor with sufficient accuracy Software requirements validation addresses the question of ldquoAre we creating the right software requirementsrdquo
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Software Requirements Clarityis the degree to which the software
requirements are unambiguous and understandable
1048708 Software Requirements Unambiguity is the degree to which each statement of the requirements can only be interpreted one way
1048708 Software Requirements Understandability is the degree to which the meaning of each statement of the requirements is easily comprehended by all of its readers
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Software Requirements Completeness1048708 is the degree to which all parts of a requirement are
specified with no missing information ie eachrequirement is self-contained1048708 Examples
ldquoradar search pulse rate must be 10rdquo is an incomplete requirement because it is missing the ldquoper secondrdquo part
The requirement ldquomissile kill assessment delay must follow the Uniform probability distributionrdquo is incomplete because it is missing the range parameter values
Also use of the placeholder ldquoTBDrdquo (to be determined or to be defined) ldquoTBRrdquo (To be resolved) ldquoTBPrdquo (To be provided) and use of the phrases such as ldquoas a minimumrdquo ldquoas a maximumrdquo and ldquonot limited tordquo are indications of incomplete requirements specification
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Software Requirements Consistency and Feasibility1048708 Software Requirements Consistency is the degree towhicha the requirements are specified using uniform
notationterminology and symbology andb any one requirement does not conflict with any other1048708 Software Requirements Feasibility is the degree ofdifficulty ofa implementing a single requirement andb simultaneously meeting competing requirementsSometimes requirements conflict with each otherIt may be possible to achieve a requirement by itselfbut it may not be possible to achieve a number of themsimultaneously
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Software Requirements Stability and Modifiability1048708 Software Requirements Stability isa the degree to which the requirements are
changingwhile the software application is under
development andb the possible effects of the changing
requirementson the project schedule cost risk quality
functionality design integration and testing of the software application
1048708 It is sometimes referred to as Software Requirements Volatility
1048708 Software Requirements Modifiability is the degreeto which the requirements can easily be changed
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Software Requirements Testability1048708 is the degree to which the requirements can easily betested1048708 A testable requirement is the one that is specified insuch a way that passfail or assessment criteria canbe derived from its specification1048708 For example1048708 the following requirement specification is not
testableldquoThe probability of kill should be estimated based onthe simulation output datardquo1048708 The following requirement specification is testableldquoThe probability of kill should be estimated by using a95 confidence interval based on the simulationoutput datardquo
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
Software Requirements Traceability1048708 is the degree to which the requirements
related to a particular requirement can easily be found
1048708 Requirements should be specified in such a way
that related requirements are cross-referenced
1048708 When it is necessary to change a requirement
those requirements affected by the changedrequirement should be easily identified by
usingthe cross-references
![[Osman bakar] classification_of_knowledge_in_islam](https://static.documents.pub/doc/80x56/58f308c11a28ab89718b4591/osman-bakar-classificationofknowledgeinislam.jpg)
