Requirements Engineering

1. Requirements Engineering Richard Jones & Bram van Oosterhout Richard.jones@anu.edu.au

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 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

4. 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

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’

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)

7. Capturing User requirementsa progression • Customer contribution declines from Concept to Preliminary Design • Supplier contribution increases from Requirements to Design Functional Specification Concept Requirements Non FS Functional Specification is the driver for the Preliminary Design Architects Designers Non Functional Specification drives the limits and opportunities for the architecture Architecture Preliminary Design 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).

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 So why not buy a product?

10. 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)

11. 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.

12. Requirements TraceabilityGives purpose to prototyping • As one specifies more detailed requirements, one needs to review implementability and cost • Especially for interfaces

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

15. Keeping Focus – staying in touch • With whom? • Client stakeholders • Internal stakeholders • Development team • How?

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

17. External Contract vs Internal Development vs Product • Are they any different? • Size is an important consideration • Who is the stakeholder?

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.

20. Scope User Interface Design Analysis Essential usecase Scenarios Design Contracts System Conceptual sequence Collaboration model Sequence diagrams Database Design Class diagrams Glossary My first success • We implemented a process that recognised the progression and feedback from requirements to design

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

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

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