COMP3110/6311, Software Analysis and Design Why do we Develop Software? To solve problems To take up new opportunities The value of Requirements "#$"%&'(%)#*+"%#)&),'$&+)& '()#-&)'$./,0.&+%/&.%1"*(%2.%# In order to select and use appropriate methods for Requirements Analysis, we must first understand the value of requirements SE Projects - The value of requirements and design Shayne R Flint Slide 1 SE Projects - The value of requirements and design Shayne R Flint Slide 2 What do people value in software? Its ability to " Solve problems " Help users to take advantage of new opportunities Cost and Schedule Quality factors " Reliability, maintainability, portability, efficiency " Human/Computer interaction, testability " Marketability, profitability How do we capture stakeholders values? Requirements - descriptions of " Behavior " Data " Constraints (eg. cost and schedule) " Properties (eg. Reliability, portability, maintainability) " Interfaces (to hardware and other software) To be of value to stakeholders, software needs to satisfy stakeholder requirements SE Projects - The value of requirements and design Shayne R Flint Slide 3 SE Projects - The value of requirements and design Shayne R Flint Slide 4
What groups of people have requirements? Anyone or any organisation that influences requirements " Users, maintainers, supporters, trainers " Analysts, designers, programmers, testers, managers " Regulators, unions, professional bodies Stakeholders Why bother with requirements? They tell us what stakeholders value A basis for agreement between stakeholders " What to build (scope) " Schedule and Cost " Acceptance criteria Failure to reach and maintain such agreement is a major cause of project failure Good requirements lead to improved agreement between stakeholders and increased likelihood that software will please the stakeholders SE Projects - The value of requirements and design Shayne R Flint Slide 5 SE Projects - The value of requirements and design Shayne R Flint Slide 6 What do we value in requirements? Characteristics of good requirements " Complete, consistent, unambiguous " Relevant, necessary " Testable, traceable " Measurable " Feasible How can we best ensure that our requirements have these characteristics? " Requirements Engineering What is Requirements Engineering? A systematic and repeatable approach to the creation and maintenance of requirements Requirements Engineering is not about light weight vs heavy weight processes. " It is not about XP vs Agile vs 'traditional' SE Projects - The value of requirements and design Shayne R Flint Slide 7 SE Projects - The value of requirements and design Shayne R Flint Slide 8
What activities do we need to think about? What do we value in each RE Activity? Elicitation Elicitation Analysis and Negotiation Documentation There is nothing here about life-cycle models or how these activities are conducted They all need to be done in some way irrespective of life-cycle Ability to identify purpose and constraints Ability to identify all stakeholders Ability to collect and organise all stakeholder needs Ability to abstract and deal with aspects/viewpoints Analysis and Negotiation Ability to reduce conflicts Ability to ensure completeness Ability to ensure compatibility Validation SE Projects - The value of requirements and design Shayne R Flint Slide 9 SE Projects - The value of requirements and design Shayne R Flint Slide 10 What do we value in each RE Activity? Documentation Ability to present requirements in an understandable, complete, and unambiguous way Ability to deliver an appropriate level of detail for all stakeholders (users, designers, testers, maintainers, trainers, managers etc.) Validation Ability to detect requirements problems (consistency, correctness and completeness) Ability to impart confidence in the requirements How do we conduct each activity? We need to select methods that best deliver the value expected by stakeholders " Based on evidence and understanding of characteristics (if we have any) Stakeholder values are often shaped by " Criticality of the software " Requirement volatility " Quality requirements " Stakeholder cultures and politics (supplier, client etc.) " Schedule and budget One size does not fit all SE Projects - The value of requirements and design Shayne R Flint Slide 11 SE Projects - The value of requirements and design Shayne R Flint Slide 12
Some methods Elicitation " Interviews " Scenarios " Soft Systems Methodologies " Observation and Social Analysis Analysis and Negotiation " Structured Analysis Data Flow, Entity Relationship and State Diagrams " Object-Oriented Analysis Class, State, Collaboration, and Sequence diagrams " Prototypes Many of the approaches listed on this slide apply to elicitation, analysis and negotiation COMP3110/6311 Some methods Documentation " Natural language and diagrams " IEEE and MIL standards " Supported and formalised by Models Tools Verification " Inspection and Reviews " Prototypes " Requirements Testing " Executable specifications (xtuml) SE Projects - The value of requirements and design Shayne R Flint Slide 13 SE Projects - The value of requirements and design Shayne R Flint Slide 14 So, what are the main challenges? Requirements value Selecting the right methods " There are many to choose from " Little evidence as to how they work in various situations Dealing with diverse groups of people " Conflict and Viewpoints " Culture and Politics Dealing with change " Learning (wrong and incomplete requirements) " Environment (the world changes) " Technology (we may be able to do new things) Understanding this chain of stakeholder values provides a basis for choosing appropriate methods Developing a 'toolbox' of methods is the easy bit. Choosing the right methods for each project is the hard bit Problem or Opportunity Software Software Development Requirements Requirements Engineering RE Activities RE Methods Design etc....... SE Projects - The value of requirements and design Shayne R Flint Slide 15 SE Projects - The value of requirements and design Shayne R Flint Slide 16
Recap - What do people value in software? Its ability to " Solve problems " Help users to take advantage of new opportunities Cost and Schedule Quality factors The value of Software Design " Reliability, maintainability, portability, efficiency " Human/Computer interaction, testability " Marketability, profitability SE Projects - The value of requirements and design Shayne R Flint Slide 17 SE Projects - The value of requirements and design Shayne R Flint Slide 18 Who might be interested in design? End users don't care? " They may, in the sense that if they believe a design is 'good', they may gain increased confidence that the software will satisfy their needs Designs are mainly used by development and maintenance stakeholders What do we value in a design? Completeness " Implementation of all requirements " Traceability Uniformity Reuse Readability, understandability Flexibility SE Projects - The value of requirements and design Shayne R Flint Slide 19 SE Projects - The value of requirements and design Shayne R Flint Slide 20
What design concepts do we know about? How do we deliver stakeholder value? Abstraction " Structural, Procedural, Data, Control Refinement Modularity Software Architecture Information Hiding Cohesion Coupling Engineering - A systematic and repeatable approach to the creation and maintenance of software designs that provide value to their stakeholders " And, again, it is not about light weight vs heavy weight processes. SE Projects - The value of requirements and design Shayne R Flint Slide 21 SE Projects - The value of requirements and design Shayne R Flint Slide 22