Lecture1 RE

BSE 3103: Requirements
Engineering (4 CU)
Dr. Joseph Kibombo Balikuddembe

For comments and issues
jbalikud@cis.mak.ac.ug.
Terms and Conditions
• NO PHONE CALLS only email queries will be answered.
• All lecture notes and additional material will be loaded on
MUELE.
• Attendance is a must as it carries 5 percent of the total mark.
• Two written tests will be given –using practical approach
scenario
• Tests will carry 40% of the total final mark while the final
exam will carry 60% of the total final mark.
• Lectures begin promptly on time.
• An attendance register will be made for each lecture.
• Pay attention to examples in class as they may come back as
exam questions.
© JK Balikuddembe - Requirements
2/16/2021 2
Engineering
Introduction to Requirements
Engineering
• Definition
– Requirements Engineering (RE) is a set of activities
concerned with identifying and communicating
the purpose of a software intensive system and
contexts in which it will be used.
– Hence, RE acts as the bridge between the real
world needs of users, customers and other
constituencies affected by a software system and
the capabilities and opportunities afforded by
software intensive technologies
2/16/2021 3
Engineering
Zooming IN
• As a set of activities: It is not a phase or stage
• Identifying and communicating: Communication is as
important as analysis
• Purpose: Quality means fitness for purpose. Cannot say
anything on quality unless you understand the purpose.
• Contexts: Designers need to know how and where the
system will be used.
• Real world needs: Requirements are partly about what is
needed
• Constituencies: Need to identify all the stakeholders – not
just the customer and the user.
• Capabilities and opportunities: and partly about what is
possible
2/16/2021 4
Engineering
Cost of getting it wrong
• Cost of fixing errors
– Typical development process:
• requirements analysis ⇒ software design ⇒ programming ⇒
development testing ⇒ acceptance testing ⇒ operation
– Errors cost more to fix the longer they are undetected
• E.g. A requirements error found in testing costs 100 times
more than a programming error found in testing
• Causes of project failure
– These are very many, check with the Standish group
2/16/2021 5
Engineering
There are different types of
requirements
• Very general requirements – these set out in
broad terms what the system should do.
• Functional requirements – define part of the
systems’ functions.
• Implementation requirements – state how the
system must be implemented
• Performance requirements – specify a minimum
acceptable performance for the system
• Usability requirements - specify the maximum
acceptable time to demonstrate the use of the
system.
2/16/2021 6
Engineering
Requirements
• Requirements set constraints and goals in the
design and objective space
– When designing systems we always have tradeoffs
between performance, cost, schedule and risk
– “Shall” … Requirements help set constraints and
define the boundaries of the design space and
objective space
– “Should” … requirements set goals once “shall”
requirements are satisfied
2/16/2021 7
Engineering
Two main spaces
• Design Space – the things we decide as engineers
• Objective Space – the things our
systems/products achieve and what our
customers care about
– 1. “The house shall sleep between 4 and 6 people”
– 2. “The total build cost should be less than $550K” 3.
“The house shall have at least 3 bedrooms”
– 4. “The house should have a fireplace”
2/16/2021 8
Engineering
Concept Question
• Is there any difference in meaning between
the words “Requirements” and
“Specifications”?
– No, they are essentially the same.
– Yes, requirements are the input to the design
process, while specifications are the output.
– Yes, specifications include the requirements, but
also contain other things such as blueprints etc
– am not sure.
2/16/2021 9
Engineering
Common requirements problem
• Requirements don’t reflect the real needs of the
customer for the system
• Requirements are inconsistent or/and are
incomplete
• Expensive to make changes to requirements once
they have been agreed
• Misunderstanding between customers, those
developing the system requirements and
software engineers developing or maintaining the
system.
2/16/2021 10
Engineering
FQAS about requirements
• What are requirements?
– A statement of system service
– A constraint on the system operation
– Description of how the system should behave
– Application domain information
– Specification of the system properties or
attributes
• How much does RE cost
– A: About 15% of the system development costs
2/16/2021 11
Engineering
Requirements vs. Specifications
• Requirements specify • Specifications describe
what the product or how the system is built
system shall/should do: and works
– Functions it shall – The Form it is made of
perform – Materials used in the
– How well it should system
perform these – Overall dimensions
– Degree of automation of – Schematics, Blueprints
the system (what etc…
operators must do) – User Interface
– Compatibility with other
devices etc
2/16/2021 12
Engineering
FQAS about requirements – Cont.
• What is requirements engineering process
– The structured set of activities involved in developing
system requirement
• What happens when requirements are wrong?
– Systems are late, unreliable, and don’t meet customer
needs
• Is there an ideal requirements engineering
process?
– NO. Processes must be tailored to individual
organization needs
2/16/2021 13
Engineering
FQAS about requirements – Cont.
• What is a requirement document?
– The formal statement of the system requirements
• Who are system stakeholders?
– Anyone affected by the system in some way.
• What is the relationship between requirements and
design?
– Requirements and design are interwoven. In principle,
they should be separate processes but in practice this is
impossible.
• What is requirement management?
– The process of involved in managing changes to
requirements
2/16/2021 14
Engineering
Purpose of Technical Requirements
Definition
• The Technical Requirements Definition Process
– Is used to transform the baselined stakeholder
expectations (input) into unique, quantitative, and
measurable technical requirements (output)
• Requirements
– Come in many flavors
– Should be expressed as well-written “shall”
statements that can be used for defining a design
solution
2/16/2021 15
Engineering
Definition
• Establishes the basis for agreement between the
stakeholders and the developers on what the product is to
do
• Reduces the development effort because less rework is
required to address poorly written, missing, and
misunderstood requirements.
– Forces the relevant stakeholders to consider rigorously all of the
requirements before design begins
– Careful review can reveal omissions, misunderstandings, and
inconsistencies early in the development cycle
• Provides a basis for estimating costs and schedules
– The description of the product to be developed as given in the
requirements is a realistic basis for estimating project costs and
can be used to evaluate bids or price estimates
2/16/2021 16
Engineering
Definition
• Provides a baseline for verification
– Organizations can develop their validation and
verification plans much more productively from a
good requirements document.
– The requirements document provides a baseline
against which compliance can be measured.
– The requirements are also used to provide the
stakeholders with a basis for acceptance of the
system.
• Facilitates transfer of the product to new users.
• Serve as a basis for later enhancement or
alteration of the finished product.
2/16/2021 17
Engineering
Interrelationships Among the System
Design Processes
2/16/2021 18
Engineering
Attributes of Acceptable Requirements
• A complete sentence with a single “shall” per numbered statement
• Characteristics for each Requirement Statement:
– Clear and consistent – readily understandable
– Correct – does not contain error of fact
– Feasible – can be satisfied within natural physical laws, state of the art
technologies, and other project constraints
– Flexibility – Not stated as to how it is to be satisfied
– Without ambiguity – only one interpretation makes sense
– Singular – One actor-verb-object requirement
– Verify – can be proved at the level of the architecture applicable
• Characteristics for pairs and sets of Requirement Statements:
– Absence of redundancy – each requirement specified only once
– Consistency – terms used are consistent
– Completeness – usable to form a set of “design-to” requirements
– Absence of conflicts – not in conflict with other requirements or itself
2/16/2021 19
Engineering
Requirements Decomposition, Allocation and
Validation
2/16/2021 20
Engineering
Technical Requirements Definition Best Practice Process
Flow Diagram
2/16/2021 21
Engineering
Some observations about RE
• RE is not necessarily a sequential process:
– !Don’t have to write the problem statement before the
solution statement"
• (Re-)writing a problem statement can be useful at any stage
of development
– RE is a set of activities that continue throughout the
development process!
• The problem statement will be imperfect
– !RE models are approximations of the world"
• will contain inaccuracies and inconsistencies"
• will omit some information.
• detailed analysis can reduce the risk that these will cause
serious problems
• but that risk can never be reduced to zero
2/16/2021 22
Engineering
Some observations about RE
• Perfecting a specification may not be cost-
effective
– Requirements analysis has a cost
– For different projects, the cost-benefit balance will be
different
• Problem statement should never be treated as
fixed
– Change is inevitable, and therefore must be planned
for
– There should be a way of incorporating changes
periodically
2/16/2021 23
Engineering
Importance of RE
• Problems
– Increased reliance on software
• E.g. cars, dishwashers, cell phones, web services,
– Software now the biggest cost element for mission
critical systems
• E.g. Boeing 777
– Wastage on failed projects
• E.g. 1997 GAO report: $145 billion over 6 years on software
that was never delivered
– High consequences of failure
• E.g. Ariane 5: $500 million payload
• E.g. Intel Pentium bug: $475 million
2/16/2021 24
Engineering
Importance of RE
• Key factors:
– Certification costs
• E.g. Boeing 777: >40% of software budget spent on
testing
– Re-work from defect removal
• E.g. Motorola: 60-80% of software budget (was)
spent on re-work
– Changing Requirements
• E.g. California DMV system
2/16/2021 25
Engineering
What do requirements Engineers do?
• Starting point
– Some notion that there is a problem” that needs
solving
• e.g. dissatisfaction with the current state of affairs
• e.g. a new business opportunity
• e.g. a potential saving of cost, time, resource usage, etc.
– A Requirements Engineer is an agent of change
2/16/2021 26
Engineering
What do requirements Engineers do?
• The requirements engineer must:
– Identify the problem /opportunity
• Which problem needs to be solved? (identify problem
Boundaries)
• Where is the problem? (understand the Context /Problem
Domain)
• Whose problem is it? (identify Stakeholders)
• Why does it need solving? (identify the stakeholders Goals)
• How might a software system help? (collect some Scenarios)
• When does it need solving? (identify Development Constraints)
• What might prevent us solving it? (identify Feasibility and Risk)
– and become an expert in the problem domain
• although ignorance is important too -- “the intelligent ignoramus”
2/16/2021 27
Engineering
Process, methods and techniques
• A notation is a representation scheme (or language) for expressing
things; e.g., Z, first order logic, dataflow diagrams, UML.
• A technique prescribes how to perform a particular (technical)
activity - and, if necessary, how to describe a product of that
activity in a particular notation; e.g, use case diagramming,
• A method provides a technical prescription for how to perform a
collection of activities, focusing on integration of techniques and
guidance about their use; e.g., SADT, OMT, JSD, KAOS, RUP(?).
• A Process model is an abstract description of how to conduct a
collection of activities, focusing on resource usage and
dependencies between activities.
• A Process is an enactment of a process model, describing the
behaviour of one or more agents and their management of
resources.
2/16/2021 28
Engineering
Where do RE methods fit into RE
processes?
• each method is appropriate for some
particular types of problem domain
– often not well-defined where they fit
• methods vary in their coverage (of RE
activities) and focus; e.g.,
• Coverage: elicitation, modelling, analysis, etc."
• Focus: goals, behaviour, viewpoints, etc
2/16/2021 29
Engineering
System engineering
• There is a close relationship between software
requirements and more general system
requirements
• Computer-based system fall into two broad
categories
– User-configured systems where a purchaser puts
together a system from the existing software products
– Custom systems where the customer produces a set
of requirements for hardware/software system and a
contractor develops and delivers that system
2/16/2021 30
Engineering
Classes of custom systems
• Information systems
– Primarily concerned with processing information
which is held in some database
• Embedded systems
– Systems where software is used as a controller in
some broader hardware system
• Command and control system
– Essential, a combination of information systems and
embedded system where special purpose computers
provide information which is collected and stored and
used to make decisions.
2/16/2021 31
Engineering
Emergent properties
• Emergent properties are properties of the system
as a whole and only emerge once after all of its
individual subsystems have been integrated
• Example of emergent properties
– Reliability
– Maintainability
– Performance
– Usability
– Security
– Safety
2/16/2021 32
Engineering
Requirement document
• The requirements document is a formal
document used to communicate the
requirements to customers, engineers and
managers
• It describes
– Services and functions which the system should
provide
– Constraints under which the system must operate
– Overall properties of the system, i.e, constraints on
the system emergent properties
2/16/2021 33
Engineering
Requirement document
• It describes
– Definition of other systems with which the system must
integrate
– Information about the application domain of the system
• E.g how to carry out particular types of computations
– Constraints on the processes used to develop the system
– Description of the hardware on which the system is to run
• The document should always include an introductory
chapter which provides an overview of the system,
business needs supported by the system and the
glossary which explains the terminology used.
2/16/2021 34
Engineering
Users of requirements document
• System customers : specify the requirements and
read them to check they meet their needs
• Project managers: use the requirements
document to plan a bid for system and to plan
the system development process.
• System engineers: to understand the system
being developed
• System testers : to develop validation tests for the
system
• Maintenance engineers: to understand the
system
2/16/2021 35
Engineering
Writing requirements
• Requirements are usually written as
paragraphs of natural language text
supplemented by diagrams and equations
– Business requirement example
• The System will provide a report detailing expenditures
of each department for a given month
2/16/2021 36
Engineering
Problems with requirements
• The meaning of requirements is not always
obvious because
• Use of complex conditional clauses which are
confusing
• Sloppy and inconsistent terminology
• Writers tend to assume that readers have
domain knowledge
2/16/2021 37
Engineering
Common Problems with Requirements
• Writing implementations (“How”) instead of
requirements (“What”)
• Forces the design Implies the requirement is
covered
• Using incorrect terms
• Avoid “support” , “but not limited to” , “etc” ,
“and/or”
• Using incorrect sentence structure or bad
grammar
2/16/2021 38
Engineering
Common Problems with Requirements
• Writing unverifiable requirements
– E.g., minimize, maximize, rapid, user-friendly,
easy, sufficient, adequate, quick
• Missing requirements
• Requirements only written for “first use”
• Over-specifying
2/16/2021 39
Engineering
Writing essentials
• Requirements are read more often than they are written, so
invest time to write readable and understandable requirements
• Do not assume that all readers of requirements have the same
background and use the same terminology common to the
business domain.
• Allow for time to review, revision and redrafting of the
requirements document
• Define standard templates for describing requirements
• Use language simply, consistently and concisely.
• Use diagrams appropriately
• Supplement natural language with other descriptions of
requirements
• Specify requirement quantitatively
2/16/2021 40
Engineering
Key points
• Requirements define what the system should provide and
define system constraints
• Requirements problems lead to late delivery and change
requests after the system is in use
• Requirements engineering is concerned with eliciting,
analyzing and documenting the system requirements.
• Systems engineering is concerned with the system as a
whole including hardware, software and operational
processes
• The requirements document is the definitive specification
of requirements for customers, engineers and managers
• The requirements document should include a system
overview, glossary of terms, statement of the functional
requirements and the operations constraints.
2/16/2021 41
Engineering
Types of document that make this
process comprehensive
• Blueprint document (for the business)
• Glossary of terms
• Business use case document
• User interface specification document
• Non functional requirement document
• Traceability matrix
• Use-case realization document
• Domain model description (design)
2/16/2021 42
Engineering

Lecture1 RE

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture1 RE

Uploaded by

Copyright:

Available Formats

BSE 3103: Requirements

Dr. Joseph Kibombo Balikuddembe

You might also like