Requirements – Architecture - Agility

R. Kuehl/J. Scott Hawker p. 1 R I T

Software Engineering Requirements Engineering and Agile Processes

 (You may be thinking) Requirements engineering model as presented is not very agile  Writing a SRS, etc. sounds like a classic heavy weight process  It is!  But, two points to consider as good software engineers: 1. Fit the software methodology and process to the problem 2. Agile processes do equivalent requirement engineering activities – still need requirements validated by stakeholders for success

R. Kuehl/J. Scott Hawker p. 2 R I T

Software Engineering Requirements and Agile

 Traditional approach – the requirements document  Agile argument against tradition  Communication gaps between authors and readers  Change cycle is too long  Challenging to capture the complete problem and system context  Brain’s capacity to retain information  Agile answer:  Continuous collaboration with stakeholders . Workshops, conversation  Stories (index cards) record conversations

Are they the requirements?

R. Kuehl/J. Scott Hawker p. 3 R I T

Software Engineering Requirements Engineering in Agile Processes Where is the Knowledge?

Requirements Eng. Agile Methodology 1. Elicitation 1. Stories 2. Iteration design, 2. Analysis customer collaboration 3. Specification 3. Stories, code, acceptance tests, unit 4. Validation tests 5. Management 4. Customer collaboration, acceptance tests 5. Planning cycle, frequent iterations

R. Kuehl/J. Scott Hawker p. 4 R I T

Software Engineering A Picture Worth a 1000 Words

Requirements Waterfall Incremental Evolutionary “Classic” or agile style Design

Always maps Construction (coding & testing) Deployment The Requirements Engineering Model The General Software Engineering Framework

R. Kuehl/J. Scott Hawker p. 5 R I T

Software Engineering R. Kuehl/J. Scott Hawker p. 6 R I T

Software Engineering Requirements Envisioning: An Agile Best Practice

 Perform some high-level requirements envisioning early in the project  Gain a common understanding of the scope of the problem  Business goals  Identify initial requirements quickly – days not weeks  Iteration 0 of an agile project (inception phase)  Also do initial architectural envisioning

Scott Ambler: http://www.agilemodeling.com/essays/initialRequirementsModeling.htm

R. Kuehl/J. Scott Hawker p. 7 R I T

Software Engineering Agile Requirements Envisioning

 Why do it?  Answer basic business questions  Reduce business risk – everyone agrees on the problem and solution scope up front  Establishes a knowledge framework to move ahead on architecture and project planning  What modeling techniques?  Usage – use cases, scenarios . Use case diagram for context  Business domain model – process flow, key data entities, business rules  User experience – story boards, prototypes

R. Kuehl/J. Scott Hawker p. 8 R I T

Software Engineering When is More Upfront Detail Recommended?

 The domain and problem space are unknown and/or complex  A commercial product (market driven requirements)  Serial project milestone governance framework  System engineering involving new hardware  Contractual obligations  Organizational culture is traditionalist

R. Kuehl/J. Scott Hawker p. 9 R I T

Software Engineering Is Agility in Conflict with Architecture Design?

R. Kuehl/J. Scott Hawker p. 10 R I T

Software Engineering Software Architecture and Agility

 Agility is not in conflict with architecture.  The question is not “Should I do Agile or architecture?”  Rather ….  “How much architecture is done up front versus how much is deferred until project requirements are more stable?”  “How much of the architecture should I formally document, and when?”  A good architecture enables agility!

R. Kuehl/J. Scott Hawker p. 11 R I T

Software Engineering How Much Architecture?

 Two activities can add time to a project schedule:  Up-front architecture design work and up-front risk identification, planning, and resolution work  Rework due to fixing defects and addressing modification requests.  Intuitively, these two trade off against each other.  Boehm and Turner plotted these two values against each other for three hypothetical projects:  One project of 10 KSLOC  One project of 100 KSLOC  One project of 10,000 KSLOC

“Balancing Agility and Discipline for the Perplexed,” B. Boehm and R. Turner, Addison-Wesley, 2004

R. Kuehl/J. Scott Hawker p. 12 R I T

Software Engineering How Much Architecture?

 A project with a million+ lines of code is enormously complex.  It is difficult to imagine how Agile principles alone can cope with this complexity if there is no architecture to guide and organize the effort.

“Balancing Agility and Discipline for the Perplexed,” B. Boehm and R. Turner, Addison-Wesley, 2004

R. Kuehl/J. Scott Hawker p. 13 R I T

Software Engineering Agility and Architecture Evaluation and Documentation

 Documentation  Write for the reader!  If the reader doesn’t need it, don’t write it. . But the reader may be a maintainer or other newcomer not yet on the project!  Evaluation  Meeting stakeholder important concerns is a fundamental agile objective  Focus on meeting the most important QA scenarios  Tailor a lightweight process

R. Kuehl/J. Scott Hawker p. 14 R I T

Software Engineering “Abstract Architecture Specification Document”

 Updated to support each incremental release (i.e., a “sprint”

Hadar, Irit, Sofia Sherman, Ethan Hadar, and John J. Harrison. "Less Is More: Architecture Documentation for Agile Development." 2013 6th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE) (2013)

R. Kuehl/J. Scott Hawker p. 15 R I T

Software Engineering Agile Architecting Heuristics

 Architects and developers need to think and work …  Top-down—design and analyze architectural structures to meet ASRs and stakeholder needs  Bottom-up—design solutions to accommodate implementation and environment constraints  Key design decisions first, then a flow of decisions as needed  Conduct experiments to analyze architecture tradeoffs (“spikes” in agile terminology)  E.g., SQL versus NoSQL database

R. Kuehl/J. Scott Hawker p. 16 R I T

Software Engineering SAiP Authors Advice

Large Systems Smaller Systems

Complex but stable Unstable requirements – get requirements – upfront agreement on major patterns architecture that apply

Unstable requirements – Limit upfront design, evaluation, candidate architecture that and documentation evolves

R. Kuehl/J. Scott Hawker p. 17 R I T

Software Engineering References

 Cockburn, Alistair, Agile Software Development, Addison-Wesley, 2002  Paetsch, Eberlein, Maurer, Requirements Engineering and Agile Software Development  Kroll and Lyons, Eclipse Process Framework Presentation, Open Unified Process Distilled, 2006  Scott Ambler, http://www.agilemodeling.com/essays/initialRequirementsM odeling.htm

R. Kuehl/J. Scott Hawker p. 18 R I T

Software Engineering