1. Requirements Engineering Dr. Richard Jones Richard.jones@anu.edu.au

2. Road Map • My background • 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. 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’

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

6. Capturing User requirements “System Engineering – dealing with complexity” Arnold, S. et al 1998

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

8. 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?

9. Keeping Focus

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

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

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

13. External Contract vs Internal Development vs Product • Are they any different? • Who is the stakeholder?

14. (A few) stories from the trenches

15. Pre-history – STATUS Product • More than a search engine • Conceived as a system • Derived from earlier concept • “What is Information retrieval”? • Requirements - Kept close to lead customers • “Dogs walking on hind-legs” • Fatal flaw – non-functional requirements

16. Computer Power Group • Professional Services - standards • Tension between product and services • Focus on technology

17. InText Systems • Tyranny of distance • “People don’t buy technology they buy solutions”

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

19. Independent Consultant • Satisfied client = getting paid • “Why was I hired”? • Someone to blame • What answer is wanted?

20. Distillery Software • What do customers really want? • Do we know better? • Focus on customers- Shift from intelligence to intelligence led investigation • Non functional requirements • mandatory requirements • Need to rearchitect solution

21. Portland Risk Analytics • Remote development • Agile development • User stories: • "As a <role>, I want <goal/desire> so that <benefit>" • Tools: • JIRA: tasks and issues • Confluence: documents/ collaboration

22. Agile Methods at Portland • Following agile manifesto • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan • First customer ship after 14 sprints (of two weeks) • Why is it working for Portland?

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

24. Questions