Agile Requirements Modeling Example 1. Initial Envisionment

More documents

Recommendations

Info

Agile Requirements Modeling Examplehttp://www.agilemodeling.com/essays/agileRequirementsExample.htmPage 6 of 133/1/2011make requirements as technology independent as possible but the reality is that many systems are alreadyconstrained to a subset of architectural options, for example SWA Online is constrained to an Internet-basedsolution, so investing time trying to abstract away from this constraint is likely of little value to your immediateefforts. Remember the principle maximize stakeholder ROI and focus your requirements modeling efforts ontasks that provide positive value.Figure 4. A high-level use case diagram for SWA Online.The use cases would be described simply, during your initial modeling efforts a point-form description of thelogic for each use case may be sufficient. You don’t need to specify the system in detail at this point, you onlyneed to gain a basic understanding of what the system should accomplish and to identify the initial scope for thesystem, and a point-form description of each use case and actor does this. If your project stakeholders allow ityou may not even need to go this far – perhaps identifying three or four use cases is enough for now. If it isthen apply the principle Model With A Purpose and stop your initial requirements modeling efforts for now,moving on to detailed modeling efforts that drill down into the modeling and implementing the requirements youhave already identified.In Figure 4 you see that I have applied the UML stereotype on a requirements diagram, yet in TheObject Primer 3/e I recommend that you apply stereotypes on analysis-level use case diagrams, typicallyreferred to as system use case diagrams because they often reflect architecture and design issues, but notrequirements-level use case diagrams. Once again the world hasn’t ended and the modeling police haven’tcharged me with crimes against software development humanity. The diagram is interesting because it showsthat it is common for models to cross process boundaries, in this case the diagram reflects what I wouldconsider to be both requirements and analysis issues.
Agile Requirements Modeling Examplehttp://www.agilemodeling.com/essays/agileRequirementsExample.htmPage 7 of 133/1/2011It’s easy to say that you need to reach a common consensus between project stakeholders but much moredifficult to achieve it in practice, even if you have overcome the common challenges to requirementsefforts. Individual project stakeholders have different backgrounds, different priorities, and differentpreferences. To build a consensus everyone needs to recognize this fact, communicate what they need fromthe system, listen to what others have to say, and be prepared to work towards a common goal. Whenever I’mworking with a group that is having a problem coming to consensus we’ll write down everyone’s issues on aplain old whiteboard (POW) where everyone in the room can see and discuss them – this visually depicts theextent of the group’s differences and provides a focus for their discussion. Sometimes we’ll remove an issuefrom the board, or better yet simply cross it out because I often want to record scoping decisions (more on thissoon), after the originator of the issue recognized that it wasn’t required or at least wasn’t important as otherissues. I also like to draw lines between contradictory issues so as to highlight the need to discuss them, oftenusing a specific color of marker for just that purpose.As the group focuses on high-level usage requirements they will often identify related business rules andconstraints, as well as technical requirements and requirements that the system may or may not need to fulfill atsome point in the future. During initial modeling you should prefer “park” business rules, constraints, andtechnical requirements, often writing them on flip chart paper or on the POW, capturing just enough informationso that you know what the requirement is when you explore it in greater detail later. The goal is to get out ofinitial modeling as quickly as possible so you want to avoid investing time exploring details – when you start toexplore details in these initial requirement sessions you put your project at risk because you are not obtainingconcrete feedback regarding your work and of suffering from analysis paralysis. Remember the principleSoftware Is Your Primary Goal and not to produce models and documents describing what your software issupposed to do. For example, as in the initial requirements modeling session for SWA Online my projectstakeholders identified several business rules and constraints pertaining to fulfillment of orders, such as how topack certain types of goods, how some products have finite shelf lives, and the pick-up procedures of ourshippers. Whenever I hear requirement such as this I ask someone to write it down, either on the POW or onan index card that is then placed on a shared desk where everyone can see it.This leads to an important point: modeling sessions are interactive. Everyone participates. At the start anexperienced modeler will need to start the effort, explaining the techniques and prodding people to pitch in.This prodding may be something as simple as asking someone to come to the POW and explaining whatthey’re talking about, filling out an index card to summarize a business rule, or writing on a Post It note to recorda data requirement for a potential report. As people become accustomed to these sorts of modeling activities,in accordance to AM’s Active Stakeholder Participation practice, you will find that you need to do lessprodding to get them to participate. Yes, some people are shy at first and may need more prodding than othersbut that’s human nature (given the choice, I prefer to have very outgoing project stakeholders involved withdevelopment efforts as opposed to shy ones that don’t speak their minds).As your team identifies requirements for the current release that you are working on they will often identifyrequirements for future releases, or potential requirements that you may need to implement at some point. Youdon’t want to lose this information, although at the same time you don’t want to invest too much time exploring itnor do you want to invest any time overbuilding your software to fulfill these potential requirements. However,there is some value to your architectural efforts – potential requirements may provide insights into the merits ofone architectural alternative over another. Change cases are a simple technique for documenting potentialrequirements, as you can see in Figure 5 which depicts two change cases for SWA Online. An important partof your scoping effort is to identify both what is currently in scope and what is currently out of scope, and byidentifying a requirement as a change case you are explicitly stating that it is currently out of scope for yourproject efforts. The effective use of change cases as architectural requirements is described in detail in theAgile Architecture article.Figure 5. Two change cases for SWA Online.Change: Expansion into North AmericaLikelihood: Very Likely
Page 1 and 2: Agile Requirements Modeling Example
Page 5: Agile Requirements Modeling Example
Page 11: Agile Requirements Modeling Example

Agile Requirements Modeling Example 1. Initial Envisionment

Create successful ePaper yourself

Delete template?

Save as template?