Software Requirements and Specification Requirements Process Requirements Process SE3821 - Jay Urbain 1
Requirements 2
Requirements No matter what product you are building, you still need to explore, understand, capture, and communicate requirements. For the right product to be built, the right requirements have For the right product to be built, the right requirements have to be discovered. … but requirements don’t come by accident. 3
Requirements Process Need a systematic process. By following a systematic requirements gathering process , you can reliably discover product requirements. The principles of a good requirements gathering and specification process should transcend application types. 4
Requirements Process • Requirements process should be iterative . – E.g., when trawling / noodling for requirements you would probably gather requirements for one business use-case at a time. • Requirements need to be written . Demonstrates the requirements can be: – communicated – understood Once written, passed to a Quality Gateway for testing – Either included in requirements spec (RS) or rejected 5
Volere Requirements Process • Customer needs/Product plan • Work context • Trawl • Prototype • Write • Quality gateway • Requirements Spec • Reuse 6
Product Plan Product Plan Initial Costs Determine: • Work Context • Product Purpose • Product Purpose Major Risks Major Risks • Stakeholders • Business Constraints Business • Project Constraints Events Client Needs Work Context 7
Work Context WORK • You can influence • Possibly change • Need to understand • Intend to study 8
Project Purpose • Describe the purpose of the product. – One sentence on what the product should do – Write this from a “business” point of view • What business advantage will this bring? • What business advantage will this bring? – Provide service that does not exist – Provide better service – Increase revenue – Streamline operations • How will you measure the advantage? – Numbers that can be tested – Quantified Goal 9
Stakeholders • Anyone with an interest in the product. • Missed stakeholders = missed requirements • Core (Principal) stakeholders Producers (technical and business personnel) • Client Client • • Customer • Users • • Non-Core stakeholders – Have knowledge needed by the core stakeholders – People who want to kill the project 10
Trawling (elicitation) Stakeholder Input Work Context Determine: • Product Scope • Product Scope • Investigate Use Cases • Brainstorm • RAD meetings Business • Scenario Oriented Elicitation Events Reuse Repository
Requirements Specification What is more important? Potential • Written requirements or Requirement • Process of writing them Trawl Prototype Potential Requirement Formalized Specify Requirement 12
Requirements Specification Formalized Why can requirements be rejected? Requirement Quality Gateway Gateway SRS Rejected Requirement 13
Waterfall Requirements • Waterfall presentation of requirements gathering should not be taken too literally. – Activities typically iterate and overlay before producing a final output. 14
Agility Guidelines • Agility does not mean the “ absence” of a process . • Agility focuses on the parts of a process that are appropriate for your project. • Not all projects can be as agile as others. Why ? 15
Project Agility • Type of project often dictates level of agility: – Number of stakeholders. – Scattering of stakeholders. – Documentation requirements – Scattered development teams. – Scattered development teams. – Legal. • Animal metaphor for type of project is common. – Rabbit – Horse – Elephant 16
Agility – Rabbit Project • How would you describe an Rabbit Project? • What level of agility and what parts of the requirements process is appropriate for Rabbit Projects? 17
Agility – Rabbit Project • High degree of agility • Typically smaller projects with close stakeholder participation • Smaller number of stakeholders • Good for XP • Good for XP • Best way to learn requirements is a whiteboard (versus written documentation review) • Prototypes and scenarios very important • Important to understand different between req. & soln. • Iterative requirements gathering, incremental development. 18
Agility – Rabbit Project • Problems with Rabbit Project? • When not appropriate? 19
Agility – Horse Project • How would you describe a Horse Project? • What level of agility and what parts of the requirements process is appropriate for Horse Projects? 20
Agility – Horse Project • Halfway agile projects • Use as much agility as possible (iterative, incremental) • Usually have constraints (project & organization) • Develop requirements for one unit of work (one business use-case) while designers start development of previous use-case) while designers start development of previous use case. • Requires the overall architecture to be in place before it can work. – How is the architecture factored into the process? • Trawling, writing, and quality steps very important • If done well, project can achieve a high degree of effectiveness without getting bogged down. 21
Agility – Horse Project • Problems with Horse Project? • When not appropriate? 22
Agility – Elephant Project • How would you describe a Elephant Project? • What level of agility and what parts of the requirements process is appropriate for Elephant Projects? 23
Agility – Elephant Project • Least agile. • Large dependable with long memories • Agility may be limited by organization • Large number of scattered stakeholders • Formal, complete product requirements may be required for domain, e.g., medical, aeronautical • Contractual obligation • Outsourcing • Even with Elephant projects, look for ways to introduce agility. 24
25
Requirements Process in Context • No end to requirements process • As soon as product is delivered, evolution starts • As people use the product, they discover new needs, new problems… which creates new requirements • Embrace this evolutionary process from the start – then • Embrace this evolutionary process from the start – then iterate, and incrementally deliver functionality 26
27
Recommend
More recommend
