Requirements engineering
1 / 24

Requirements Engineering - PowerPoint PPT Presentation

  • Uploaded on

Requirements Engineering. Dr. Richard Jones 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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Requirements Engineering' - jamese

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Requirements engineering

Requirements Engineering

Dr. Richard Jones

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

A little rj history
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


  • “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
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
Capturing User requirements

“System Engineering – dealing with complexity” Arnold, S. et al 1998

Why is requirement engineering important
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
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?

Keeping focus system vision statement
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
Keeping Focus – staying in touch

  • With whom?

    • Client stakeholders

    • Internal stakeholders

    • Development team

  • How?

Keeping focus system requirements
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
External Contract vs Internal Development vs Product

  • Are they any different?

  • Who is the stakeholder?

Pre history status product
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

Computer power group
Computer Power Group

  • Professional Services - standards

  • Tension between product and services

  • Focus on technology

Intext systems
InText Systems

  • Tyranny of distance

  • “People don’t buy technology they buy solutions”

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

Independent consultant
Independent Consultant

  • Satisfied client = getting paid

  • “Why was I hired”?

    • Someone to blame

    • What answer is wanted?

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

Portland risk analytics
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

Agile methods at portland
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?


  • 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