Delivering Business Value with Agile Approaches to Requirements, continued

This post is a continuation of a previous post found here.

Changes Dave believes are coming with respect to agile-run projects and my own commentary on these:

• Requirements engineers make decisions, they are not just documenters. Expect to see that product owners are the BAs. They will less often be called systems analysts, and more often called product owners. A few years ago, we shifted from calling our requirements team members “Business Analysts” and started calling them “Product Managers” because that’s really what they have to do – own the product, even if it’s just an internal IT system.


• BAs/Product Owners will be empowered to make decisions and not just sit around waiting on sign-off. They must be experts in the business. They must work with development, not just document for them. Once they do this, they can start to make very smart decisions about what should or should not make it in the product.


• Agile is not a fad, even NASA is doing it. That said, we will see variations on agile as it grows and evolves.


• The development team can add value about requirements, so collaborate with them. They don’t all just want to gold-plate scope or push back on what’s in or out – they love to build products, so use that to your advantage.


• The business is not always right, so you still need to ask questions. BAs/Product Owners must push back when something doesn’t make sense.


• Agile is actually seen to increase the value of requirements – just make them more solution focused, and not just about doing lots of documentation.

And finally, Dave made my favorite quote from RE’09: The difference between UML 1 and UML 3 is that we moved the stick hands from being straight out to angled downwards. He can make jokes like this since he actually worked on it!

Delivering Business Value with Agile Approaches to Requirements

I attended a keynote at RE’09 in Atlanta that I wanted to go back and post a summary of and my thoughts on. And just to be completely honest, this is a rarity. For whatever reason, I really tend not to get much value out of keynote talks – either they are too technical, the speaker isn’t great at well, speaking, or they are so out there I cannot engage in it. Today was different though, it was captivating for me. This one was given by Dave West of Forrester Research. The talk was titled “Developing Business Value with Agile Approaches to Requirements”.


To be fair, he had my attention at the first slide – it was a picture of a dog doing agility. When I talk about agile, I use such a picture too since I personally do agility with my dog! Anyway, the content of the talk proved to be interesting. Some will say it wasn’t anything new. Others will argue with what he said. But for me, his ideas were very tightly aligned with our experiences and ideas about agile and requirements so I like that it built on what I already knew and gave me new ideas to think about. The great thing is he has a much larger pool of resources to survey and confirm his ideas. Here are a few of the points of interest.


He talked to what is being adopted with respect to agile and among those things: Agile itself is being adopted. Scrum practices are as well. He also sees engineering practices such as early testing, integrated builds, and re-factoring. But most of note, he is most commonly seeing a hybrid of approaches– more of an agile than an Agile approach. I think this is relevant as I hear company after company say “agile didn’t work for us”. In reality for many companies it probably doesn’t in its purest of form. Or perhaps it requires trying it more than once, learning from mistakes (do we really think Waterfall worked the first time either?!?!).


Some really positive things he believes we are seeing now include frequent delivery, increased business involvement with more collaboration, and changes in team organization towards smaller teams and more of a team focus in general. His thought on when agile is best used: Complex projects where there are problems to be solved and the solution is unknown.


Dave spoke to the common friction points between traditional requirements approaches and agile:

• Delivers requirements vs collaboration on the product
• Where in the process you engage vs. iterative
• Requirements that are out of date, long/hard to read, solution focused, take way too long vs. collaborative and timely requirements

Some of the issues that you must be careful about with agile: Often the customer has no time because they are doing their day-job (the one you are trying to help in some way with software!). There are often many customers to involve in the requirements efforts, not just one or two to quickly jot down stories with. The customers are often distributed so you have to bake in time to work with all of them alone and together. Agile is reliant on good communication but stereotypically, developers don’t communicate well. We cannot ignore analysis - processes require analysis and solutions require thought - so take time to do these.


I will continue this post in a day or so with thoughts on changes that Dave thinks we are starting to see, as well as my personal thoughts on his thoughts!

An example of Blueprint in Use on an Agile Project

I attended a talk by folks from BluePrint and Lexis Nexis at BAWorld on Tuesday at BAWorld: Boston called "Requirements Definition for Agile Projects". The first bit of the talk was just an intro to agile and why it is useful on the projects. The part that I found most interesting was from Kathleen McGoey who owned business analysis on lawyers.com - she effectively gave a verbal case study of their team using agile and Blueprint to deploy this site. This was refreshing because she was brutally honest about the state of their organization 2 years ago, some of her dislikes about other tools, and their experiences with agile not going well. However, she also then talked about how their culture is changing now and what is working really well. This talk was great because it was effectively a great sales-pitch for Blueprint, but it was given by an actual user....and you could tell she was being honest about it.

Blueprint is meant to be a BA tool. They are closely partnered with HP and it integrates to Quality Center for QA use as well. From a quick glance of things she mentioned or showed, it looks like it allows you to manage the list of features in a backlog, low-fidelity wireframes, diagrams that look a lot like visio, export to Word, and import from Excel. We are still using Borland's Caliber happily, but I'm obviously always looking at all the tools on the market to see what people are really liking and/or disliking, what new features are coming about, what's easy to use, etc.

A bit about the lawyers.com project - they were executing 3-12 week sprints and the requirements definition is about 2 weeks ahead of sprint cycles. She made a very wise comment - templates and processes are good to an end, but only if the BA knows what they are doing already. She spoke of junior analysts who are given templates and when you look at their work products you think “Oh no! what are you doing!”. I think we’ve all probably seen that. You can use the templates and processes to train them, but they aren’t enough, but they aren’t enough.

Another neat thing she briefly mentioned was the idea of doing something like pair-programming, but where the pair consists of a BA and a user experience expert – so together they are designing the wireframes. I haven’t tried it, typically our individuals are doing both activities.

Anyway, it was good to hear the “how it works” story from Lexis Nexis. And I haven't used Blueprint myself, but I am certainly interested to hear others' experiences with the tool, so please comment if you have used it.

A Better Way to Write a Use Case: Plain English

I was talking to a colleague recently about use cases and it got me thinking about my evolution as a use-case-writer. I used to do formal use cases exclusively – where they very clearly denoted system and user steps (whether in one list or 2 columns), preconditions, triggers, Postconditions, etc. etc. etc.

After years of writing and teaching about formal use cases, I have to confess, I rarely write them now. Sometimes I still teach about them, I think it’s important to know how to write good ones. But the reality is that as we move towards shorter-iterations on our projects, the less formal we need them to be in the use case itself. What I’m finding works really well are these use cases written more like user stories. They may still have a linear set of steps, but the big difference is they are written in a more readable language of plain English with slightly less structure.

I’m oversimplifying but to make my point, instead of:

1. System displays shipping fields

2. User enters shipping info

3. System displays payment options

4. User enters payment options

I could simply say:

User enters shipping and then enters payment information.

I’ve conveyed the same information without stating the literally obvious points. You have to be careful here though, don’t assume the obvious incorrectly! Now, before you agile non-documenters jump up and down and say “I told you so!”, I want to be clear – you still need to write something down. This is the part that many projects neglect to tackle is the next level of detail. You still need to capture specific functional requirements for this use case/user story – there are our typical RML™ – with people, systems, data models to be created that describe those requirements, So I use the user stories, just like I used a formal use case – stepping through each “step” and determining what details need to be specified for building the software. Oh and one more thing, I do still use preconditions, triggers, and actors in the header – just makes it cleaner to call those out up top.

Six Ways To Be An Agile Adolescent

Do you get along with everybody? Are you universally loved in your office?

Then you are a failure.

There are those that are born great and those that are told they are great guys. Especially working in an Agile environment, the requirements stakeholder has to be… well…

A screaming, pouting adolescent.

They don't call it a scrum for nothing: It's a battle. If you're not arguing, not giving voice to every seemingly petty impulse, you're not doing your job. But don't worry, I can help you tap into your inner child. Start with these techniques:

1. The Eye Roll: This classic we all mastered as teenagers-- stop a line of BS before it starts (you should know it when you see it, you're the adolescent, after all).

2. Belch if You're Bored: You should never be bored in a scrum. If you're bored you're not on task. If you're in a meeting [which should be a warning sign in and of itself] try a combo: belch, then eye roll, then moan "What are we doing here?" Sartre would approve.

3. The Pedantic Reductionist Humiliation (PRH): When you need to prove a point, paint the picture out in irreducible terms and make other people say it back to you, ESPECIALLY if they don't want to. Chase people down and pin them; the rhetorical equivalent of "quit hitting yourself".

4. Appropriation of the Winning Argument: This is a great technique. If you find yourself wrong, just switch sides immediately and congratulate yourself.

5. The Schizoid Handshake: When things get really heated, wax philosophic and say "I really appreciate the interaction here. This intellectual energy is critical to creating a good product." Feelings don't get hurt as easily if everybody thinks they're part of an exclusive group, like hanging with Dorothy Parker at the Gonk**.

6. Forget Everything by Monday: Remember everything that happened in the trailing 48 hours then forget about it (this includes grudges) unless it is a plotter printout posted on a wall in your immediate work area.

The only nice thing about the business of being a child is that, while perhaps unpleasant, your role is critical.

Without you, things stop moving.

RML™ Requirements Model 5 - The Data Flow Diagram (DFD)

The Data Flow Diagram (DFD) is a very useful part of the Requirements Modeling Language (RML™). The Structured Analysis Wiki contains a great explanation of how to create a DFD, so I’m not going to cover that information here. Instead, I’m going to provide one answer to the question “How do I know when to use a DFD?” This answer comes from my own (unique) view of the world, so some of you probably won’t relate to it, but others will--I’m sure there is at least one more out there…

Sometimes I have what I think of as an "equation" in my head. In vague terms, I may be thinking “Customer Data + Product Data + Input from Sales Rep + Taxes = Order”. But that's not really right, nor is the equation a good representation of the information.

And, the “equation” also misses a few other particulars about creating an order that I’d like to convey: Sales Reps update customer data, the Finance staff maintains the rules for the tax calculations, and orders flow to the Order Fulfillment system after creation.

The data flow diagram is great for representing all of this. Here’s my “equation,” expressed as a data flow diagram:

I have found that business users, as well as developers, react well to this model—it provides a “big picture” with which to begin a conversation about creating an order. It paints exactly the picture I want to convey and validate when I’m thinking “Customer Data + Product Data + Input from Sales Rep + Taxes = Order”.

Display this picture, and you’ll get some interesting questions and comments:

• How is customer data populated initially?


• Does the order fulfillment system update the order store with information about the fulfillment of the orders?


• Where does the product data come from?


• Are all of the tax rules manually entered, or is there also an electronic source for them?


• And, maybe, “No, that’s wrong, updating customer data isn’t a separate process. Customer updates need to automatically flow out of changes made when creating the order.”
  

One note: it doesn’t have to be technically perfect to be useful. I often provide “conceptual” DFDs, in that I intentionally provide conceptual, but not technical information. For example, conceptually, there is a “products” data store. Technically, there may be multiple stores: product list, product descriptions, etc. The important thing is that they work together to provide product data. Developers and architects are very receptive to this; they understand I’m illustrating the behaviors of the system without defining the implementation (which, after all, is their job). Oh, and how does the audience know it is conceptual? I put the word “conceptual” in the title!

You may notice I didn’t number my processes. That’s because I rarely decompose them and many people tend to take the numbering as ordering. So, for my usage, numbering adds confusion rather than clarity.

Happy diagramming!

Related Articles:

How To Choose A Software Requirements Model

Six Requirements Models For Agile Projects

What does "requirements sign-off" mean in agile?

I was recently working with a cusotmer on a project using an agile methodology. The organization was moving towards trying to do most of their projects in agile, so the nature of this is that they have a lot of non-agile pieces to their methodology still in place. We were cruising along in defining requirements and development was well into the first sprint, when the project manager told me we had a target date for the requirements to be signed off.

Wait a minute! Hold your horses folks! Sign-off? In an agile project?

I took it upon myself to remind her of the development methodology of choice for our project… and that she was asking me about sign-off in a methodology where it doesn’t really make sense…. one where the users have the right to prioritize whatever features they want in the backlog at any time. So if they forgot some features during our elicitation process, then that’s ok, they just need to figure out where to put it in the prioritized backlog, realizing something else may drop off. She laughed immediately reassuring me she hadn't lost it and that she understood completely, but the corporate process required this! So we began the discussion of what a “sign-off” would mean to us.

In the end, I think we got pretty creative with it. We did have lots of requirements in the form of user stories and other models like process flows, state tables, etc. And we were working closely with the users to elicit and review them. So what we asked them to do was to “sign-off” that at that moment in time, there were no major requirements missing, that they knew about, and there were no major issues with what we’d written down, that they knew about. The key is this means that they did in fact look at them, they participated in the activity and so development is not developing a prototype of something too far off basis. But it also keeps open their right to realize something new they need after they see it, think about it, sleep on it, or whatever.

What I really like about this is approach is that it doesn’t force anyone into a corner where they feel like they are signing away their life over a massive requirements document that they barely understood or that they are signing on a dotted line to say they are mostly perfect and got it all the first time around. So more or less, I think our version of sign-off allows the spirit of agile methodologies to prevail still.

Diagrams 2008 Day 2 Highlights: Tools, Tools, and more Tools

Most of today’s sessions were all about Tools. Most exciting was a demonstration of Inkkit and LADDER by Beryl Plummer and Tracy Hammond. A colleague of mine had already told me about the exciting work done by Dr. Hammond and her Sketch Recognition Lab at Texas A&M University , but today, I actually had a chance to see it in action. Imagine entering a requirements elicitation session in a room with no whiteboard. In most cases, the requirements engineer would need to either collect several sheets of freehand drawings, or (if you are lucky enough), allow the subject matter experts to capture their thoughts on a tablet PC. In either case, the RE still needs to transcribe these drawings to Visio or some other tool. This is not only time-consuming, but transcribing introduces the possibility of errors. It was so impressive, that I think I will begin testing it in elicitation sessions.
Here is a picture of Ladder in Action. Includes some "before" and "after" the sketch recognition algorithm is applied. Note the various types of drawings:








As a side note, Dr. Hammond mentioned that designing the algorithm for the entity-relationship diagram is especially tricky, and is still not completely refined. The sticking point? Those pesky claw-foot connectors which depict the cardinality of the relationship between two entities.
Some other high points:

• David Barker-Plummer of Stanford University gave a demo of Hyperproof. Initially, this was designed to grade logic proofs for undergraduate students, but it has been and can be extended to capture and check reasoning for any type of system.
• A presentation of the VAST system by Peter Cheng. This tool was designed to create schedules for large institutions with many complicated interrelated constraints. The way in which so much information was presented, but yet easily understood was quite clever.

The day ended with a tour of Mühlfelder Brauhaus followed by quite possibly one of the top 5 best meals of my life: A six-course Bavarian meal with a spectacular dessert. And of course, plenty of beer from the brewery.



Oh, by the way, the winners of the best paper (and the Nokia N810s) were Atsushi Shimojima and Yasuhiro Katagiri for their excellent paper An Eye-tracking Study of Spatial Constraints in Diagrammatic Reasoning. I also had the opportunity to meet Atsushi Shimojima, and he is a really nice guy. The best student paper went to Krista DeLeeuw and Mary Hegarty for What Diagrams Reveal about Representations in Linear Reasoning, and How They Help. This paper, among other things, describes the power that visual tools can provide in helping people think about problems.

Diagrams 2008 Day 1 Highlights: From Models to Code (and Back)

Today's Keynote address, given by Wilhelm Schäfer, discussed something called Mechatronic UML: A subset of UML 2.0 with applications in industries which intersect EE and ME, and actually in use on the Railcab project.

This subset of UML is used to generate code for systems in which there is heavy interaction among several different components—especially designed for safety-critical applications (such as public transportation). Although such a language is definitely beyond the scope of most requirements engineers, it made me reflect on the “Requirements/Design/Implementation” distinction, in that even though the distinction between requirements and design will never be resolved, the distinction between design and implementation always seemed more concrete. I think that Schäfer’s project has sort of blown a hole in this belief for me, as the design work done in UML is used to generate code directly and successfully in very complex systems. Now, if there were a requirements modeling language which could be translated into Mechatronic UML (or even a fragment of it), it would not only blur the line between requirements and design even more, but also the line between requirements and implementation. Scary.

Also, today during the welcome and introduction, it was revealed that the authors for the best paper in the conference would be awarded two Nokia N810s tablets! Cool! One of the great things about a conference such as this, is that despite the diverse interests of many of the participants, all of them almost universally believe in leveraging technology to solve complex representational problems. As a result, I would say that around 50% of the people here are using a tablet PC or convertible.

At the poster session, I encountered some interesting studies about diagram placement and comprehension of supporting text. It turns out that placement of diagrams in relation to the supporting text may not be as important as our intuitions might reveal. Additionally, diagrams with which one must interact in order to view (e.g., a clickable thumbnail) are more likely to be ignored. The sample for this study was college students, however, and not requirements engineers or their audiences. It would be interesting to run a similar study with an RE orientation. By the way, there was plenty of German snack food at the reception and poster session—pretzels, dark bread, wurst, mustard. And of course, beer. It was a long and cold—but happy—walk back to my hotel.

How to Prepare for Software Requirements Sessions with Your Users - Tip 2

Last time we talked about organizing your time.

Today's suggestion: Prepare Your Requirements Models In Advance

Prepare draft requirements models in advance of the meeting. The reality is that good requirements analysts do in fact know quite a bit about the business processes and requirements. There is a misconception that they should remain unbiased; however, these individuals become experts in the systems they are capturing requirements for and that expertise should be utilized to its full advantage.

As an example, if you are going to cover a topic with a user about how he or she does a task, then you can try to come up with the obvious use cases in advance. You can then take it one step further and actually try to write the header information and normal course for the use cases. Similarly, you may find it valuable to draft state diagrams, where you capture the states and transitions that are obvious and highlight the unknown ones for completion in the meeting. Virtually all requirements models can be pre-drafted if you know a little bit about the business.

In doing these models ahead of time, you will find yourself jotting down lots of questions in the margins, like "What really happens at this step?" or "Should they do X instead of Y?". Even if you throw away the draft model because it was all wrong (which rarely happens), there is still a value from the time investment because you came up with a list of detailed questions. Essentially this is a brainstorming tool for you.

Starting from a blank slate can seem like a daunting task, so once you have draft models, in the meetings with users, you can use these models to work from. Similarly to the authoring experience, reviewing the models will spur questions in the reader’s mind. Therefore they make an excellent tool with which to facilitate a user meeting.

See another great post on how to choose a requirements model.

Come back for part 3 next!

Signing Out from INCOSE 2008

Well, I hate to say it, but my week here at INCOSE 2008 has come to an end. And though I must say goodbye to my INCOSE friends, I'm not headed home quite yet - first I will enjoy a few days in Amsterdam, just up the road from Utrecht.


A few final comments from this side of the pond (some of these are purposefully non-INCOSE related to keep it interesting!):

• After hours of listening to talks about process, I have to say - systems engineering processes are heavy! There are images dancing in my head of things like a project plan circle diagram that even in a 3x3 foot printout, you have to squint to read the tasks. Or there are the matrices that don't even come close to fitting on a page, yet they try to squeeze them in for demonstration of a concept.
• I spoke with some systems engineers who, when I explained what Seilevel does, said things like "Really? Requirements as a job?" or "You have a business around that?" or "I never thought of them as a separate thing, they were just some other task on my project that maybe got done." or my favorite "Why are you at a systems engineering conference then?"
• It's a small world. In a city of more than a million, today I ran into a fellow INCOSE member from San Antonio, TX on my way back from the Rijksmuseum.
• Most all of the presenters like to use words on slides! Seriously, I almost think it must have been in the presentation requirements - "Must have wordy slides". Perhaps I can suggest Beyond Bullet Points.
• I enjoyed reconnecting with my friends from what I like to call "Seilevel Europe", the HOOD Group (and mind you, they would and should probably call us "HOOD Group USA"). We have very similar companies, with similar methodologies, in different parts of the world. If you haven't heard of them, I encourage you to take a look at their work.
• Sadly, Holland just lost in the quarter finals of the Euro 2008. I say sadly because I've actually become quite fond of watching the "Oranje" games (or maybe just the crowds hanging outside of bars).
• I once again was reminded that so many Americans have a tendancy to focus on just us. This is by no means a generalization though. I personally like to intermix with those from other countries, though I'm also quite guilty of speaking American and little else. Anyway, it was frustrating to listen to talks from Americans who would only quote American statistics, or American events, or American disasters. My European friends were quick to point it out for me "Oh another American talk!". Thankfully some of the talks were very different than that though, making me much more proud.
• We should do more peer reviews, but not for the obvious reasons. A systems engineering organization requires team members to be on peer review boards, not so much for improving the quality of the deliverables, but more importantly, to expose the engineers to more projects and ideas that they can then apply to their own projects. Brilliant, I say!
• The field of systems engineering has many many many outstanding success stories, ranging from the Airbus 380 to the ProRail system of the Netherlands. There are lots of great lessons to be learned here that can be applied to much simpler projects. But really, how cool would it be to build a network of thousands of kilometers of rail or to put a new airplane in the air?

Anyway, in a few days, I will return home with many fond memories of the Netherlands and INCOSE 2008.

INCOSE 2008 - Can You Build an Airplane with an Agile Approach?

With all of the buzz about Agile, I have to mention that here at INCOSE 2008, I did not hear a single mention of it (except when I asked about it directly!). Actually, that’s not true, at one point I was excited to see a speaker’s slides which referenced applying agile processes as a step in a project. Then he spoke to the slide and I started to suspect he meant agile in the pure definition of the word, to move quickly. At the end, someone asked him the specific question as to whether he meant the agile software methodology and he clarified that he did not. So I left the conference wondering - with all the discussions about processes at a conference like this, why are they not ever speaking about agile?

Airplanes Are Not Software Requirements

My first guess - this probably relates to some of the core differences between systems and software engineering. I am going to over simplify this and just say that it is about scale. Systems projects are just a superset of software and hardware projects, integrating and deploying some combination of these. The teams of people deploying systems projects are quite large. And many of the projects discussed here are for government or regulated systems where specification and traceability is necessary. I could see how subsets of systems projects could in fact be developed using agile (pure software components), but I’m not convinced that an entire end-to-end project can. To put this in context, imagine you are building an airplane - a very commonly referenced type of systems engineering projects. Can you see this working using agile?

All skeptism aside, I do think that iterative development most certainly could work well on systems projects, and most people here would not argue that. In fact, I would love it if we could find examples of agile working on systems projects, because the number one feeling I get at systems engineering conferences is a craving for lighter processes.

I decided to do a little research outside the conference walls, and low-and-behold, I found a great article on this exact topic – “Toward Agile Systems Engineering Processes” by Dr. Richard Turner of the Systems and Software Consortium. The article is very well laid out, and I highly recommend reading it. He defines what agile is and what he believes the issue why most systems engineering projects are not agile. For example, he suggests that executives and program managers tend to believe that the teams involved have perfect knowledge about systems we are building, so we can plan them out in advance and work to a perfect execution against a perfect schedule.

Agile Can Work With Complex Systems

He talks to how to the agile concepts can work in systems projects. Here are a few examples summarized from his article:

• Learning based: The traditional V-model implies a one-time trip through, implying one time to re-learn. However, perhaps the model can be re-interpreted to allow multiple iterations through it to fulfill this.
• Customer focus: Typically systems engineering processes do not support multiple interactions with the customer throughout the project (just up front to gather requirements). That said, he references a study indicating the known issues with that on systems projects. Therefore, perhaps processes should be adapted to allow for this, particularly allowing for them to help prioritize requirements throughout projects.
• Short iterations: Iterations are largely unheard of because the V-model is a one-time pass through the development lifecycle. That said, iterations of prototyping through testing could be done in systems engineering in many cases. The issue is in delivering something complete at the end of each iteration. He suggests that this is not as important to the customer in large deployments as is reducing risk, validating requirements, etc. This is a great point to rememember the airplane example! Could we have even a working part of an airplane after 2 weeks? What about even the software to run a subsystem on the aircraft?
• Team ownership: Systems engineering is very process driven, so this one is tricky. Dr. Turner puts the idea out that perhaps allowing the systems engineers to drive it instead of the process to drive them, while more uncomfortable for management, might produce more effective results.

So while he does give some suggestions to adapt systems engineering processes to be more agile, I don’t think this will qualify as purely agile. And frankly if it we tried it, I think I'd be fearful to be in the airplane! But to quote Dr. Turner directly “…other hand, agility is much more a state of mind or philosophical approach than a set of rules that have to be followed regardless of appropriateness.” Using that idea, combined with what I saw at INCOSE 2008, I can see some definite opportunities for improvements for the field systems engineering.

Six Requirements Models For Agile Projects

When working on any agile project, most people will agree there is still a need to understand requirements. With the quick iterations of these projects, it’s more important than ever, to use visual models to capture the requirements. When done correctly, they are easier and quicker to create and understand than a list of written requirements. Selecting the appropriate models will vary by project; however, we can suggest a few common choices that work well.

High Level Models
At the beginning of the project, it is important to get a quick picture of the breadth of the project. This picture will help the team determine where to dive for depth. It is really important that these models are done as broad strokes, with just the bare minimum information. To get a sketch of that big picture, consider these models:

• Context diagram – This diagram simply sets the landscape of the project, clearly indicating the scope boundaries.

• Org chart – This is a model that often already exists in the organization. It can quickly help identify all the possible users or user groups that should be included in the project discussions.

• Data flow diagram – This is a quick sketch of the key pieces of data flowing through the system, including where it is created, changed and deleted. The data in this diagram should only be data that is important to the users of the system. They will help to identify the most important data and systems to work with.

• High-level process flow – Let’s start by saying this is nothing fancy or complex. The flow diagram should describe the major obvious steps. Again, the purpose is to sketch it simply, to give the big picture. In no way is it meant to be comprehensive or detailed.

Imagine one of your iterations requires bringing in new users to the team. These four models will give them an opportunity to quickly see the big picture of what this project is and where it is going, without having to read a 200 page spec (since there isn’t one!). You can also use them with your users to prioritize the most important pieces of the system for the iterations.

Models in the Iterations
Once you have prioritized the work for the first iteration, the two most popular models are likely to be:

• User stories – You can write these for the most important parts of the flow. They will be less detailed than the traditional use cases, supplying just enough depth to be developed.

• Wireframes – These will be connected to high-risk user stories, when sketching an interface might be a good aid to help the users explain what they need. These should be done in a quick modeling tool, or just by hand.

There will be other models. Sometimes you won’t even use these. The common theme in all of them is to create a visual representation of the requirements because it is faster to create and read. And with them all, only do the bare minimum necessary.

Four Ways To Improve Agile Requirements Management

One of the challenges of Agile projects is ensuring that the requirements remain “Agile”. While requirements are not necessarily neglected on Agile projects, an Agile project may erroneously take a waterfall approach to requirements.

Here are some simple techniques to adapt your requirements management effort to an agile project. The quotes at the beginning of each section are from the “Principles Behind the Agile Manifesto” at http://agilemanifesto.org .

1. Communicate Requirements Often And Effectively

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Two problems with email is that it is inefficient and easy to ignore. Email thread discussions can be long, tedious, and annoying. Despite the advances in emoticons over the past several years, it is also impossible to interpret non-verbal communication in email.

Resolutions to discussions around requirements, scope, and implementation will be resolved much quicker and to the satisfaction of more stakeholders through a meeting or hallway conversation.

If moderating a large number of email discussions is part of your current requirements process (for example, after the initial draft of the requirements doc is published), perhaps it’s time to schedule regular meetings at key points during the release cycle.

Established method: Email discussion

Suggested method: JAD, daily stand –ups

2. Use Collaboration Tools For Requirements Management

“Business people and developers must work together daily throughout the project.”

This is related to the other “C”—Communicate.

Communication on a project should be visible to all stakeholders in the project. Changes to requirements should be pushed out quickly and universally, without having to remember whether the developer who started last week is on the dev@mycompany.com mailing list.

Manage requirements in a central location where all stakeholders have immediate and easy access. An internal website for requirements and product management information is a much more efficient way of reaching your audience than emailing copies of documents to your stakeholders.

If possible, include collaborative tools like wikis and discussion boards as part of your website.

Established method: Word documents attached to emails

Suggested method: Wiki/Web page with automated change notification

3. Add Models And Wireframes To Your Requirements

“Continuous attention to technical excellence and good design enhances agility.”

If applicable, use wireframes or mockups with callouts as a supplement to your requirements.

This is especially useful on projects which call for enhancements to existing interfaces. A wireframe with brief text descriptions is easily consumable, and conveys a large amount of information very efficiently.

Include more detailed descriptions of wireframes and mockups in your user stories, and publish it on your internal product management website (see #2 above).

Established method: Design document/specification; Text-only documents.

Suggested method: Internally-hosted website with wireframes and bulleted descriptions

4. Keep User Stories Simple

“Simplicity--the art of maximizing the amount of work not done--is essential.”

Ensure your user stories describe one and only one feature, and only the functions necessary for that feature.

Looking through a large, monolithic document which describes multiple features to be implemented across several releases wastes time.

Breaking your user stories down into descriptions of the most basic functions required for a feature also helps maintain release discipline.

Resist the temptation to include requirements for “nice to have” or “future” functionality. This clutters the user story with unnecessary information.

Established method: Large document which describes many features

Suggested method: Wiki page/website with a single page devoted to a single feature. Include links to related features.