1. Requirements Engineering
Richard Jones &
Bram van Oosterhout

2. Road Map Our backgrounds Definitions
Why is requirement engineering important?
Why is it difficult especially for s/w systems
Keeping focussed
Contract vs product development requirements
Stories from trenches
Wrap up

3. A little RJ History Maths degree in Dublin 1962-66
PhD in Relativity
Program to do my algebra
UK government science
Wrote STATUS, one of first search engines
Australian s/w companies 1984-now
Both product and contract dev. Range of roles
Includes three start-ups, one SME
Also as independent consultant

4. A little BvO History Chemistry/Physics degree in Utrecht (NL) 1971
PhD Solid state chemistry
Ab-Initio calculations in solid state chemistry
Research Fellow ANU RSC
Lab automation
Multi national and Australian companies 1981-now
Fixed price contracted business applications
5 to 100 person years

5. Definitions
“Requirements engineering - a systems and software engineering process which covers all of the activities involved in discovering, documenting and maintaining a set of requirements for a computer-based system”. Wikipedia
Requirements are 'what & 'why' not 'how’
RICHARD
Requirements are system requirements not necessarily s/w requirements
Was called system analysis (perhaps broader)
BRAM
In the traditional waterfall model of the systems or software engineering process,[6] requirements engineering is presented as the first stage of the development process, with the outcome being a requirements document or Software requirements specification. In fact, requirements engineering is a process that continues through the lifetime of a system as the requirements are subject to change and new requirements must be elicited and documented and existing requirements managed over the lifetime of the system.
Name came into fashion in 1990s

6. Some Requirements Subprocesses
Requirements elicitation
discovering requirements from system stakeholders
Requirements analysis and negotiation (prioritisation)
checking requirements and resolving stakeholder conflicts
Requirements specification
documenting the requirements in a requirements document
System modeling
deriving models of the system, often using a notation such as uml
Requirements validation
checking that the documented requirements and models are consistent and meet stakeholder needs
Requirements management
managing changes to the requirements as the system is developed and put into use
(from wikipedia)
RICHARD
Not dwelling on these.
presented as chronological stages. in practice, there is considerable interleaving
The sub-processes that are part of a general requirements engineering process vary widely, depending on the type of system being developed and the specific practice of the organization developing the requirements.
may include:
Requirements elicitation – (Used to be gathering)
Requirements analysis and prioritisation - checking requirements and resolving stakeholder conflicts
Requirements specification
System modeling - Unified Modeling Language
Requirements validation - consistent and meet stakeholder needs
Requirements management - managing changes to the requirements as the system is developed and put into use

7. Capturing User requirements a progression
Non Functional Specification
drives the limits and
opportunities for the
architecture
Functional Specification
is the driver for the
Preliminary Design
Designers
Architects
Architecture
Design
Requirements
Functional
Specification
Non FS
Concept
BRAM
In a contracted software development environment, the Customer usually establishes the Concept (of Operations). A set of requirements is derived from this, usually with some input external advisors. This set of requirements is then released in a Request for Tender. Suppliers respond to the Request for Tender with a proposal and the Customer then selects a Supplier.
At this point the Supplier starts the Requirements Engineering.
The Customer and Supplier collaborate in the development of the Requirements, Functional Specification and Non-Functional Specification. The Supplier’ expertise will lead the engineering effort
The customer knows much about the business requirements that drive the system requirements. But the customer is not expected to understand the issues around building a system. That is where the Supplier contributes expertise.
As a consequence, the customer will have much input into the concept, and less into the Functional Specification. The supplier will have little input in the concept, but will have much to contribute to the Functional Specification.
The interaction between the customer and the supplier is directed towards casting the business requirements into system requirements.
The target audience for the final documentation, the Functional and non-Functional Specification, is the Designer. This places an additional demand on the Supplier, because both audience groups (Customer and Designer) need to understand and accept the contents of the Functional Specification As a consequence, a format with a body largely directed towards the Customer and annexes with additional information of a more technical nature is appropriate. Cross references between these parts are essential.
The contribution to the design is overwhelmingly from the Supplier. The design is a technical document and must be a technical description of the implementation of the envisaged system. The Customer will need to provide input, partly to clarify issues, and sometimes to review the product. At this stage the client is expected to have the technical expertise to evaluate the product from design. If they don’t have it, they can hire it.
Design is sometimes seen as the mapping of the requirements into the architecture to produce the implementation.
Architecture makes general statements that places a boundary on the solution space. Things like: Which hardware, software, language, database, operating system, etc. it will present strategies like: how to do error handling, login, communication, display, etc…
Preliminary Design is focused on a breakdown of the solution space in usually technically or functionally coherent areas. This breakdown helps to distribute the work over multiple designers, builders and testers later and provides opportunities to manage risk and deliver in an evolutionary fashion.
Design will deliver requirements for the construction team. These should be complete, consistent and unambiguous. They must be testable.
The major interface is from the analyst to the designer and from the designer to the builder.
Customer contribution declines from Concept to Preliminary Design
Supplier contribution increases from Requirements to Design

8. Why is requirement engineering important?
'Requirements failures are the prime cause of project failures‘ Robert Glass
“The hardest part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later”
(Brooks 1995).
RICHARD
Glass investigated failed projects over several decades
Eliciting, analyzing, and writing good requirements are the most difficult parts of software engineering. However,
to quote Karl Wiegers (2004), “If you don’t get the requirements right, it doesn’t matter
how well you do anything else.”
One can end up doing a perfect job of building the wrong product.
My second project Testing MVS 370/175

9. Why is requirements engineering hard?
Far too many
Unstable due to late changes
Ambiguous/ incomplete
No ongoing stakeholder involvement
No focus on wider system characteristics
Developers lose focus or have the wrong mind set
“Instead of thinking how IT can change the world, one should think of how business situations inform the changes in IT systems”
Ajay Kaul Managing partner AgreeYa Solns
RICHARD
users often have problems in articulating their requirements. tasks users currently perform and those that they might want to Perform.
Can often be represented in use cases to describe the outwardly visible requirements of systems.
The requirements engineer may choose a particular path through a use case, a scenario, in order to better understand some aspect of using a system [41].
Now talk about keeping focus

10. Requirements Traceability It is hard
277 Contract Features (20 pages, Concept/Requirements) from the customer were interpreted as
193 Use Cases (4 Specifications, 233 pages, Analysis)
239 Scenarios (15 Specifications, 481 pages, Analysis)
205 User Interfaces (20 Specifications, 2523 pages, Design)
BRAM
Requirements traceability – It is hard.
There are many requirements and they describe more and more detail as the engineering progresses.
And the requirements change. Not because we don’t know what is required conceptually, but because we don’t know what and how the concept can be implemented.
To illustrate the volume, here are some figures from a project I worked on (20 person years):
277 Contract Features (20 pages, Concept/Requirements) from the customer were interpreted as
193 Use Cases (4 Specifications, 233 pages, Analysis)
239 Scenarios (15 Specifications, 481 pages, Analysis)
205 User Interfaces (20 Specifications, 2523 pages, Design)
The Supplier needs to ensure that the implementation described in the 2523 pages of design meets all needs expressed in the 20 pages of Contract Features. If needs are not met, the system may not be fit for purpose. If additional needs are met, then they are likely to be work in addition to the contracted work.
This is done by tracing the requirements from Concept through Requirements, Functional and Non functional specification to Design.
Tracing is done through the Requirements Traceability Matrix (RTM)
The RTM can be implemented at different levels of abstraction. For example:
Feature > Use Case > Scenario > User Interface; Or
Feature > Use case paragraph > Scenario line > User Interface implementation detail

11. Requirements Traceability Supports change
The Requirements Traceability Matrix is bidirectional.
From Concept to Implementation Component
And the converse
When a requirement changes, the RTM helps to determine the scope of the impact.
When an implementation needs to be adapted, the RTM helps determine whether the adaptation comprises the Concept of Operation.
Requirements traceability – Supports change.
The RTM will tell you that a particular Concept is implemented through a collection of requirements described in the Functional and Non-Functional specifications.
The RTM also tell you that each of those requirements is implemented through one or more subsystems and the specific component within a subsystem.
Conversely, when the RTM is maintained, it can answer questions like:
When departmental Authentication system is changed, which Requirements will be affected?
When the security classification system is updated, what requirements are affected and how does this change the implementation.

12. Requirements Traceability Gives purpose to prototyping
As one specifies more detailed requirements, one needs to review implementability and cost
Especially for interfaces
BRAM
Requirements traceability – gives purpose to prototyping.
The RTM will tell you that a particular Concept is implemented through a collection of requirements described in the Functional and Non-Functional specifications.
The RTM also tell you that each of those requirements is implemented through one or more subsystems and the specific component within a subsystem.
This allocation of requirements to the design must be anticipated during the engineering of the requirements.
For instance:
The requirement “The system shall provide invoice details to the departmental Finance system” needs an investigation on how the system can interface with the departmental Finance system. Electronic? ? Fax? These are three different technical interfaces.
And then: Can we guarantee delivery?
The requirement: “The system shall report the promotion of entities to production status to the system administrator” needs an investigation on whether the report is by , log, report or dashboard. Whether the responsibility is with the workflow component (can it do that) or the entity promoted. The workflow system may only be able to log event. The entity may not be aware of the transition at the point it occurs.
These trade offs must be considered during the requirements engineering. The consequences of delay can be considerable.
For instance,
an interface may not support expected functionality.
the cost of alternatives can be very different.
the support cost of alternatives can be very different
the implementation timeframes can be very different

13. Keeping Focus

14. Keeping Focus - System vision statement
"For a mid-sized company's marketing and sales departments who need basic CRM functionality, the CRM-Innovator is a Web-based service that provides sales tracking, lead generation, and sales representative support features that improve customer relationships at critical touch points. Unlike other services or package software products, our product provides very capable services at a moderate cost.“
‘Crossing the chasm: Marketing and Selling High-Tech Products to Mainstream Customers ’ Geoffrey Moore
RICHARD
CRM Customer relationship management
This product vision model helps team members pass the elevator test.
Shared vision with business team.
It follows the form:
For (target customer)
Who (statement of the need or opportunity)
The (product name) is a (product category)
That (key benefit, compelling reason to buy)
Unlike (primary competitive alternative)
Our product (statement of primary differentiation)
Important part of scrum
Who is going to buy the product? Who is the target customer? 
Which customer needs will the product address? 
Which product attributes are critical to satisfy the needs selected, and therefore for the success of the product? 
How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points? 
What is the target timeframe and budget to develop and launch the product?

15. Keeping Focus – staying in touch
With whom?
Client stakeholders
Internal stakeholders
Development team
How?
RICHARD
For the life of the project.
Meetings: something to show. Excite stakeholders
Will they read stuff

16. Keeping Focus - System requirements
Non functional requirements
Drives quality
Extent to which it meets user requirements
User relevance
Reliability
Availability
Safety/ security
Developer relevance
Testability
Maintainability
Portability
Reusability
RICHARD
The ilities

17. External Contract vs Internal Development vs Product
Are they any different?
Size is an important consideration
Who is the stakeholder?
RICHARD
Internal projects are worst: Holding requirements steady against the rest of company
BRAM
Size is an important consideration.
For 5 person year projects, most people can keep requirements in their head. Formality is useful, but an overhead on the project
For 50 person year projects, a few people will eat and drink the requirements, but the implementation will be across multiple groups and products. Their functions and purpose will be known to specialists. Common functionality would be implemented in a product. Business specific functionality would be contracted. Requirements engineering is needed in some parts to maintain coherence. Traceability is required to manage change.
For 500 person year projects, no single person will be across the full set of requirements and their implementation. The project requires requirements engineering to maintain purpose, coherence and control. Traceability is essential to maintain integrity of the system
If product is there a sale already? Probably not let anyone from dev team talk to them. You are initially probably doomed to talk to internal business people.

18. (A few) stories from the trenches

19. My first failure
A large system was built with a broad Concept of Operations in mind.
Specifications were written with a view to get a system that the customer wanted.
Towards User Acceptance Test, it appeared that the customer desires did not match the concept of operation, we had more Change requests than requirements and the integrity of the system fell apart.
The project was cancelled.
BRAM
The issue here is that the customer emphasized certain features over others (Prioritisation, which is reasonable)
And we did not ensure that the lower priority features were implementable in the architecture that supported the high priority features.
UAT discovered the missing features, insisted they would be implemented. The supplier pointed at the signed of architecture documents and requested changes, because the architecture could not support the low priority features.

20. My first success
We implemented a process that recognised the progression and feedback from requirements to design
Collaboration
Essential
usecase
Glossary
Scenarios
User Interface
Design
Contracts
System
sequence
Design Class
diagrams
Scope
Conceptual
model
Analysis
Database
Sequence
BRAM
The success was small to begin with (10 pyears project) over multiple years with a small team.
But we did derive requirements from the scope (how we collect features). Developed them through scenarios and managed change throughout.
Release based delivery has become routine, providing early visibility to emerging functionality.

21. InText Systems Tyranny of distance
“People don’t buy technology they buy solutions”
Borland Software product development methodology
Equal Partnership
BUMs: Business unit mangers
DUMs: Development unit managers
Time + resources = functionality + ilities
Time is the most critical
Strict prioritisation of requirements
DUM really controlled destiny
RICHARD
Mgt changes ex Borland exec . Borland v innovative s/w company in 1980s 1nd 1990s. V engineering focussed. Blockbuster products: Turbo Pascal, C++, V competitive w Microsoft.

22. Encompass Corporation
Remote development
Agile development
User stories:
"As a <role>, I want <goal/desire> so that <benefit>"
Tools:
JIRA: tasks and issues
Confluence: documents/ collaboration
RICHARD
Support for process from top. They do walk the walk
Tightly knit dev team though physically seperated
Two very strong customer facing BAs, who are fully engaged with customer and team
Quite light-weight. Suited to small teams

23. Conclusions One size does not fit all Lots of things don’t work
What does?
Ongoing communication
Partnership/ trust
Not blame/ suspicion
Focus on the system
The right documentation

24. Questions