Institutt for datateknikk og informasjonsvitenskap Inah Omoronyia
Requirements Specification and Testing Part 1
TDT 4242
TDT 4242
Learning outcome
To understand the challenges in requirements engineering and the importance of getting requirements right in software projects.
Requirements Development:
Requirements elicitation: Goal oriented requirements engineering - GORE
Quality issues in requirements
Requirements elicitation with boilerplates (templates)
Advance use cases
Requirements Management:
Requirements traceability, Requirements prioritisation
Requirements handling (COTS, outsourcing subcontracting etc)
Requirements for embedded systems and information systems
Requirements through user stories and scenarios
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 The RE process:
Ultimately:
defined operational capabilities
satisfy
business needs
TDT 4242
Challenges in Requirements Engineering
TDT 4242
Challenges in Requirements Engineering Importance of getting requirements right: • 1/3 budget to correct errors originate from requirements
Source: Benoy R Nair (IBS software services)
TDT 4242
Challenges in Requirements Engineering Factors that make a software project challenging:
Source: Benoy R Nair (IBS software services)
TDT 4242
Challenges in Requirements Engineering Why projects are cancelled:
Source: Benoy R Nair (IBS software services)
TDT 4242
Learning outcome
To understand the challenges in requirements engineering and the importance of getting requirements right in software projects.
Requirements Development:
Requirements elicitation: Goal oriented requirements engineering - GORE
Quality issues in requirements
Requirements elicitation with boilerplates (templates)
Advance use cases
Requirements Management:
Requirements traceability, Requirements prioritisation
Requirements handling (COTS, outsourcing subcontracting etc)
Requirements for embedded systems and information systems
Requirements through user stories and scenarios
TDT 4242
Requirements Development Requirements 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 (covered in TDT4175 Infosys) • Focus: • Methodical extraction of concrete requirements from high level goals • Requirements quality metrics
TDT 4242
Requirements Development 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 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
Requirements Development (What are we trying to avoid) • Ambiguity • Incompleteness • Forward referencing • Un-testable requirements • Noise • Opacity • Inconsistency • Unfeasibility • Poor writing
TDT 4242
Concrete requirements from high level goals Problem world and machine solution: The problem to be solved is rooted in a complex organisational, 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
Concrete requirements from high level goals Formulation of requirements statements:
Statement scope: • Phenomenon of train physically moving is owned by environment •
Cannot be directly observed by software phenomenon
• The phenomenon of train measured speed being non-null is shared by software and environment •
Controlled by a speedometer in the environment and observed by the software.
• Requirement statements differ in scope across phenomenon TDT 4242
Concrete requirements from high level goals Formulation 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
Concrete requirements from high level goals Formulation of requirements statements: 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 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
Concrete requirements from high level goals Formulation of requirements statements: Software requirement: • A prescriptive statement enforced solely by the software-to-be. • Formulated in terms of phenomena shared between the software and environment. • Example: The doorState output variable shall always have the value ‘closed’ when the measuredSpeed input variable has a non-null value
TDT 4242
Concrete requirements from high level goals Formulation of requirements statements: Domain property: • Descriptive statement about the problem world • It is expected to 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
Concrete requirements from high level goals Goal orientation in requirements engineering: A goal is an objective the system under consideration should 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 (devices, humans, software etc. ) – Agents
TDT 4242
Concrete requirements from high level goals Goal oriented requirements engineering: Goals can be stated at different levels of granularity: – High-level goal: A goal that requires the cooperation of many agents. – Normally stating strategic objective related to the business: – Example: 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
Concrete requirements from high level goals Goal statement typology:
Statement typology with goals
TDT 4242
Concrete requirements from high level goals Goal types:
TDT 4242
Concrete requirements from high level goals Behavioral goal specialization:
TDT 4242
Concrete requirements from high level goals Goal categorisation: Similar to requirements categorizations:
TDT 4242
Concrete requirements from high level goals Goal categorisation: 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
Concrete requirements from high level goals Goal categorisation: • Non-functional goal: States a quality or constraint on service provision or development. • Example: •
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 m.p.h • 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 me more user friendly
TDT 4242
Concrete requirements from high level goals 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
Concrete requirements from high level goals Goal refinement: Example
TDT 4242
Concrete requirements from high level goals Goal refinement tree: Refinement links are two way links: One showing goal decomposition, other showing goal contribution
TDT 4242
Concrete requirements from high level goals Goal refinement tree: Goal feature annotation
TDT 4242
Concrete requirements from high level goals Requirements quality metrics: • Qualita've Goal-‐Requirements tracing: – An approach to requirements refinement/abstrac8on that makes it less likely to generate trace links that are ambiguous, inconsistent, opaque, noisy, incomplete or with forward referencing items
TDT 4242
Concrete requirements from high level goals Requirements quality metrics: – Ambiguity: Requirement with terms or statements that can be interpreted in different ways. Sub-‐class concept reasoning:
– Example: – Scenario: ACC domain – There are two types of vehicles: Ego-‐vehicle and forward vehicle – Requirement statement: – The maximum speed of a vehicle in a busy road shall be 10mph – What type of vehicle do we mean?
TDT 4242
Concrete requirements from high level goals Requirements quality metrics: – Inconsistency: Requirement items that are not compa8ble with other requirement nodes. Predefined seman8c reasoning
– Example: – Scenario: Industrial automa8on and PLC – Requirement statement: – R1 The PROFIBUS in factory automa8on shall have a short reac'on 'me of 60ms.The maximum speed of a vehicle in a busy road shall be 10mph – R2 PROFIBUS used in hazardous areas in process automa8on shall have a low power dissipa'on of 3.6 W
– Inconsistency: Short reac8on 8me contradicts low power dissipa8on TDT 4242
Concrete requirements from high level goals Requirements quality metrics: – Forward Referencing: Requirement items that make use of problem world domain features that are not yet defined. One of E, C or D need to be mapped to a requirement item
– Example: – Scenario: ACC – There are no requirements sta8ng the proper8es an ego-‐vehicle preset speed – Requirement statement: – ACC system shall maintain the preset speed of an ego-‐vehicle if there is no forward vehicle – Forward referencing: Undefined aWributes – Who sets the preset speed? – What is the value of the preset speed?
TDT 4242
Concrete requirements from high level goals Requirements quality metrics: – Opacity: Requirement items for which ra8onal or dependencies are invisible. – Mul8ple unrelated concept mapping. A is not related to B
– Example: – Scenario: Railway – Requirement statement: – Each 8me the freight train doors are closed the passengers must all be seated. – Opacity: – There is no visible rela8onship between freight train and passengers. – freight trains are used for carrying goods.
TDT 4242
Concrete requirements from high level goals Requirements quality metrics: – Noise: Requirement items that yield no informa8on on problem world features. X refers to a concept undefined in the domain
– Example: – Scenario: Railway – Requirement statement: – The train system shall guarantee safe transporta8on of all passengers to their residence. – Noise: – Residence is an unknown concept within the train domain – The train can only transport passengers to the nearest train sta8on and not their residence
TDT 4242
Concrete requirements from high level goals Requirements quality metrics: – Completeness: The needs of a prescribed system are fully covered by requirement items without any undesirable outcome. – No requirement item mentions the goal concept Z
– Home work: Demonstrate an example of a scenario where the requirements for a system is incomplete. TDT 4242
Concrete requirements from high level goals Where do the goals come from: • Preliminary analysis of the current system. • Systema8cally by searching inten8onal keywords in documents provided, interview transcripts etc. – E.g. ‘objec8ve’, ‘purpose’, ‘in order to’ etc. • Itera8ve refinement and abstrac8on of high-‐level goals: • By asking the how and why ques8on. – Results in a goal refinement tree • Approaches: • KAOS – Goal driven requirements acquisi8on • Matulevicius, R. and Heymans, P., “Visually Effec8ve Goal Models Using KAOS”, Lecture Notes in Computer Science, 2007
TDT 4242
Summary • Goals can be defined at different levels of abstraction • There are different types of goals: • Behavioral or soft goal • There are different categories of goals • Functional and non-functional • Goal refinement provides a natural mechanism for structuring complex specifications at different levels of concern: • Goal refinement graph • Exercise 1
TDT 4242
Lecture 2
To understand the challenges in requirements engineering and the importance of getting requirements right in software projects.
Requirements Development:
Requirements elicitation: Goal oriented requirements engineering - GORE
Quality issues in requirements
Requirements elicitation with boilerplates (templates)
Advance use cases
Requirements Management:
Requirements traceability, Requirements prioritisation
Requirements handling (COTS, outsourcing subcontracting etc)
Requirements for embedded systems and information systems
Requirements through user stories and scenarios
TDT 4242
Lecture 2
Professor Elizabeth Hull, Professor Ken Jackson and Dr Jeremy Dick http://www.requirementsengineering.info/ TDT 4242
Requirements elicitation with boilerplates What is a boilerplate? • Boilerplates is a set of structures that can be used to write requirements for safety critical systems. • Makes explicitly high-level system based on concept classification and attributes
TDT 4242
Requirements elicitation with boilerplates What is a boilerplate? • Boilerplate = Concrete requirement + attribute and template used + values to attribute • Template The shall be able to • Classification • Capability • Properties/attributes stakeholder capability • Values to attribute stakeholder = occupants
capability = to travel in comfort
• Concrete requirement The occupants shall be able to travel in comfort TDT 4242
Requirements elicitation with boilerplates Example boilerplate:
The shall be able to at a maximum rate of at least times per .
Classification: Capability/Capacity (Maximise, Exceed) Example instantiation:
= order entry clerk = raise an invoice = 10 = hour
Giving
"The order entry clerk shall be able to raise an invoice at a maximum rate of at least 10 times per hour."
TDT 4242
Requirements elicitation with boilerplates • Motivation for use of templates: • A substantial amount of the documents available for requirements analysis are written as free text. • Text has the advantage of unconstrained expression. • There is, however, need for a common understanding of concepts used to express the requirements and relations between them. • Lack of common understanding makes requirement specifications expressed as free text prone to ambiguous representations and inconsistencies.
• Template based textual requirements specification (or boilerplate): • Will introduce some limitations when representing requirements as free text but will also reduce the opportunity to introduce ambiguities and inconsistencies. • Provides an initial basis for requirements checking • Easy to understand by stakeholders compared to more formal representations TDT 4242
Requirements elicitation with boilerplates Functional requirements example: • Functional requirements from a SafeLoc system
The robot control system shall stop the robot within 10 milliseconds if a gate is opened to the zone where the robot is operating The robot shall only be allowed to start when all gates are closed and the reset button is pushed The robot shall stop if it tires to move into a zone already occupied by an operator
• Suggested boilerplates:
TDT 4242
Requirements elicitation with boilerplates Non functional requirements and soft-goals example: •
Non-‐functional requirements and soft goals fits into the same BPs as Functional requirements • Suitability: The shall be able to to • Maturity: The shall be able to for a sustained period of at least • Fault tolerance: While the shall be able to or While the shall be able to TDT 4242
Requirements elicitation with boilerplates Form interface
TDT 4242
Requirements elicitation with boilerplates Home work: Transfer the following ACC requirements into boilerplates stating clearly their possible concept classifications and attributes: 1. The minimum selectable time gap for steady state vehicle following shall be greater than or equal 1s for all speeds. At least one time gap tau in the range 1.5s to 2.2s shall be provided. 2. The ACC system shall be able to determine the speed of the egovehicle 3. The driver shall always have the authority to override the ACC system engine power control
TDT 4242
