Embed Size (px)
Citation preview
Requirements Engineering
Richard Jones &
Bram van Oosterhout
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 requirementsa progression
• Customer contribution declines from Concept to Preliminary Design
• Supplier contribution increases from Requirements to Design
Non Functional Specificationdrives the limits and opportunities for the architecture
Functional Specificationis the driver for the Preliminary Design
Designers
Architects
Architecture Preliminary DesignDesign
RequirementsFunctional Specification
Non FSConcept
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 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
Requirements TraceabilityIt 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
Security Scenarios
Performance Scenrios
Login UI requirements
User Administration Interface requirements
Authentication System Interface requirements
Authorisation System Interface requirements
Requirements TraceabilitySupports 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 TraceabilityGives 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
Collaboration
Essential usecase
Glossary
Scenarios
User Interface Design
Design Contracts
System sequence
Design Class diagrams
Scope
Conceptual model
Analysis
Database
Sequence diagrams
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
