inah omoronyia and tor stålhane requirements specification and testing an introduction
Post on 09-Jan-2016
44 Views
Preview:
DESCRIPTION
TRANSCRIPT
TDT 4242
Inah Omoronyia and Tor Stålhane
Requirements Specification and TestingAn introduction
TDT 4242
Institutt for datateknikk oginformasjonsvitenskap
TDT 4242
Challenges in Requirements Engineering
What is a requirement?•What a system must do (functional): System requirements•How well the system will perform its functions (non-functional): System quality attributes
definedoperationalcapabilities
businessneeds
satisfy
The RE process:
Ultimately:
TDT 4242
Challenges in Requirements Engineering
TDT 4242
Challenges in Requirements Engineering
Source: Benoy R Nair (IBS software services)
Importance of getting requirements right:1/3 budget to correct errors originate from requirements
TDT 4242
Challenges in Requirements Engineering
Source: Benoy R Nair (IBS software services)
Factors that make a software project challenging:
TDT 4242
Challenges in Requirements Engineering
Source: Benoy R Nair (IBS software services)
Why projects are cancelled:
TDT 4242
Requirements Development - 1Requirements Elicitation:The process of discovering the requirements for a system by communication with customers, system users and others who have a stake in the system development.
Requirements gathering techniques
• Methodical extraction of concrete requirements from high level goals
• Requirements quality metrics
TDT 4242
Requirements Development – 2 Effects of Inadequate Requirements development – Ariane 5:(An expendable launch system used to deliver payloads into geostationary transfer orbit or low Earth orbit)
Ariane 5 succeeded Ariane 4. Wrong implicit assumptions about the parameters, in particular the horizontal velocity that were safe for Ariane 4 but not Ariane 5.
• horizontal velocity exceeded the maximum value for a 16 bit unsigned integer when it was converted from it's signed 64 bit representation.
• Ariane 5: component (requirements) should have been designed for reuse – but the context of reuse was not specified.
Cost of poor requirements in Ariane 5• Data overflow on launch• Self-destruction of the complete system• Loss > 500 Million EUR
TDT 4242
Requirements Development – 3 Effects of Inadequate Requirements development – Airbus:
Requirement: Reverse thrust may only be used, when the airplane is landed.
Translation: Reverse thrust may only be used while the wheels are rotating.
Implementation: Reverse thrust may only be used while the wheels are rotating fast enough.
Situation: Rainstorm – aquaplaning
Result: Crash due to overshooting the runway!
Problem: erroneous modeling in the requirement phase
TDT 4242
Problem world and machine solution
The problem to be solved is rooted in a complex organizational, technical or physical world.
• The aim of a software project is to improve the world by building some machine expected to solve the problem.
• Problem world and machine solution each have their own phenomena while sharing others.
• The shared phenomena defines the interface through which the machine interacts with the world.
E-commerce world
Requirements engineering is concerned with the machine’s effect on the surrounding world and the assumption we make about that world.
TDT 4242
Formulation of requirements statements
Statement scope:
• Phenomenon of train physically moving is owned by environment. It cannot be directly observed by software phenomenon
• The phenomenon of train measured speed being non-null is shared by software and environment. It is measured by a speedometer in the environment and observed by the software.
TDT 4242
Two types of requirements statements
• Descriptive statements: state properties about the system that holds regardless of how the system behaves. E.g. If train doors are open, they are not closed.
• Prescriptive statements: States desirable properties about the system that may hold or not depending on how the system behaves
• Need to be enforced by system components• E.g. Train doors shall always remain closed when the
train is moving
TDT 4242
Formulation of system requirement
A prescriptive statement enforced by the software-to-be.
• Possibly in cooperation with other system components• Formulated in terms of environment phenomena
Example: All train doors shall always remain closed while the train is moving
In addition to the software-to-be we also requires the cooperation of other components:
• Train controller being responsible for the safe control of doors.
• The passenger refraining from opening doors unsafely
• Door actuators working properly
TDT 4242
Formulation of software requirement
A prescriptive statement enforced solely by the software-to-be. Formulated in terms of phenomena shared between the software and environment.
The software “understand” or “sense” the environment through input data
Example: The doorState output variable shall always have the value ‘closed’ when the measuredSpeed input variable has a non-null value
TDT 4242
Domain properties
A domain property:• Is a descriptive statement about the problem world• Should hold invariably regardless of how the system behaves• Usually corresponds to some physical laws
Example:
A train is moving if and only if its physical speed is non-null.
TDT 4242
Goal orientation in requirements engineering – 1
A goal is an objective that the system under consideration shall achieve.
– Ranges from high-level strategic to low-level technical concerns over a system
– System consist of both the software and its environment. Interaction between active components, i.e. devices, humans, software etc also called Agents
TDT 4242
Goal orientation in requirements engineering – 2
Goals can be stated at different levels of granularity:– High-level goal: A goal that requires the cooperation of
many agents. They are normally stating strategic objective related to the business, e.g. The system’s transportation capacity shall be increased by 50%
– Requirement: A goal under the responsibility of a single agent in the software-to-be.
– Assumption (expectation): A goal under the responsibility of a single agent in the environment of the software-to-be. Assumptions cannot be enforced by the software-to-be
TDT 4242
Goal statement typology
TDT 4242
Goal types
TDT 4242
Behavioral goal specialization
TDT 4242
Goal categorization – 1
Goal categories are similar to requirements categories:
TDT 4242
Goal categorization – 2
Functional goal: States the intent underpinning a system service
• Satisfaction: Functional goals concerned with satisfying agent request
• Information: Functional goals concerned with keeping agents informed about important system states
• Stimulus-response: Functional goals concerned with providing appropriate response to specific event
Example: The on-board controller shall update the train’s acceleration to the commanded one immediately on receipt of an acceleration command from the station computer
TDT 4242
Goal categorization – 3
Non-functional goal: States a quality or constraint on service provision or development.
Accuracy goal: Non-functional goals requiring the state of variables controlled by the software to reflect the state of corresponding quantities controlled by environment agent
E.g: The train’s physical speed and commanded speed may never differ by more than X miles per hour
Soft goals are different from non-functional goals. Soft goals are goals with no clear-cut criteria to determine their satisfaction.
E.g: The ATM interface should be more user friendly
TDT 4242
Goal refinement
A mechanism for structuring complex specifications at different levels of concern.
A goal can be refined in a set of sub-goals that jointly contribute to it.
Each sub-goal is refined into finer-grained goals until we reach a requirement on the software and expectation (assumption) on the environment.
NB: Requirements on software are associated with a single agent and they are testable
TDT 4242
Goal refinement: Example
TDT 4242
Goal refinement tree – 1
Refinement links are two way links: One showing goal decomposition, the other showing goal contribution
TDT 4242
Goal refinement tree – 2
Goal feature annotation
TDT 4242
Requirements quality metrics – 1
Qualitative Goal-Requirements tracing:An approach to requirements
refinement/abstraction that makes it less likely to generate trace links that are ambiguous, inconsistent, opaque, noisy, incomplete or with forward referencing items
TDT 4242
Requirements quality metrics – 2
TDT 4242
Requirements quality metrics – 3Forward Referencing: Requirement items that make
use of problem world domain features that are not yet defined.E, C and D need to be mapped to a requirement item
TDT 4242
Requirements quality metrics – 4Opacity: Requirement items for which rational or
dependencies are invisible.
Multiple unrelated concept mapping. A is not related to B
TDT 4242
Requirements quality metrics – 5
Noise: Requirement items that yield no information on problem world features. X refers to a concept undefined in the domain
TDT 4242
Requirements quality metrics – 6Completeness: The needs of a prescribed
system are fully covered by requirement items without any undesirable outcome.
No requirement item mentions the goal concept Z
Quality metrics on a requirements set provides useful understanding, tracking and control of requirements improvement process.
Requirements quality metrics
TDT 4242
Where do the goals come from?
We get goals from:
• Preliminary analysis of the current system.
• Systematically by searching intentional keywords in documents provided, interview transcripts etc. E.g. ‘objective’, ‘purpose’, ‘in order to’.
• Iterative refinement and abstraction of high-level goals: By asking the how and why question. Results in a goal refinement tree
• Approaches: KAOS – Goal driven requirements acquisition.
TDT 4242
Summary
Goals can be defined at different levels of abstraction
There are two types of goals: Behavioral or soft goal
There are several categories of goals, e.g. • Functional and non-functional• Goal refinement provides a natural mechanism
for structuring complex specifications at different levels of concern:
• Goal refinement graph
top related