Transcript Requirements Engineering - Home - CS - CECS

Requirements Engineering
Richard Jones &
Bram van Oosterhout
[email protected]
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
A little RJ History
• Maths degree in Dublin 1962-66
• PhD in Relativity 1966-70
– Program to do my algebra
• UK government science 1970-84
– Wrote STATUS, one of first search engines 1972++
• Australian s/w companies 1984-now
– Both product and contract dev. Range of roles
– Includes three start-ups, one SME
– Also as independent consultant
A little BvO History
• Chemistry/Physics degree in Utrecht (NL) 1971
• PhD Solid state chemistry 1972-1976
– Ab-Initio calculations in solid state chemistry
• Research Fellow ANU RSC 1977 - 1981
– Lab automation
• Multi national and Australian companies
1981-now
– Fixed price contracted business applications
– 5 to 100 person years
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’
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)
Capturing User requirements
a progression
Concept
Functional
Requirements
Specification
Non FS
Architects
Functional Specification
is the driver for the
Preliminary Design
Non Functional Specification
drives the limits and
opportunities for the
architecture
Architecture Preliminary Design
Design
• Customer contribution declines from Concept to Preliminary Design
• Supplier contribution increases from Requirements to Design
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).
•
•
•
•
•
•
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
So why not buy a product?
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)
277 Contract Features
31 Release Features
46 Release Features
77 Release Features
123 Release Features
Search Scenarios
Create Scenarios
Login UI requirements
Security Scenarios
User Administration
Interface requirements
Performance Scenrios
Authentication System
Interface requirements
Authorisation System
Interface requirements
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
Gives purpose to prototyping
• As one specifies more detailed requirements, one
needs to review implementability and cost
– Especially for interfaces
Keeping Focus
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
Keeping Focus – staying in touch
• With whom?
– Client stakeholders
– Internal stakeholders
– Development team
• How?
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
External Contract vs Internal
Development vs Product
• Are they any different?
– Size is an important consideration
• Who is the stakeholder?
(A few) stories from the trenches
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.
My first success
• We implemented a process that recognised the
progression and feedback from requirements to design
Scope
User Interface
Design
Essential
usecase
Scenarios
Conceptual
model
Contracts
System
sequence
Design
Collaboration
Sequence
diagrams
Design Class
diagrams
Glossary
Analysis
Database
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
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
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
Questions