Category Archives: Requirements management software

Software used or designed to be used for managing requirements. We look at individual applications and what they can do, as well as features or use cases that drive what those applications should do.

Requirements Management Journey – Part 0

Requirements Management – I’m embarking on a journey to help several teams manage their requirements with their existing systems and tools.  This is the first in a series of articles, where the rubber meets the road.  I’ll look at both the theory and the realities of what works (and doesn’t) in practice.  I hope you’ll come along for the ride.
Continue reading

UML Statecharts and Documenting Business Rules

turtle seeking the ocean

In yesterday’s article we compared use cases and UML statecharts as tools for discovering business rules. James Taylor asked a question about how we would document those rules, and then followed up my comment response with an article about business rules and RUP. In this article we move the conversation slightly forward – recognizing that we’re slowly entering the ocean of business process management.

UML Statechart and State Transition Table Artifacts

There are two primary artifacts that come from using a UML statechart to discover business rules. The first is the statechart itself.

uml 2.0 statechart

This is a primary artifact from the perspective of object oriented analysis (OOA). It provides a large amount of information in a dense, yet incredibly easy to absorb format. It is the ease of understanding that makes this a great tool for validating your understanding of the business process with stakeholders.

There are three elements of information that are documented in a UML statechart. The first is the list of possible states. In the example above, the rounded rectangles represent the possible states for a customer-order (Shipped, Delivered, etc). The second is the exhaustive list of all allowed state transitions (“Deliver Order” is the event that causes a transition from Shipped to Delivered). The third element is the events that describe (or cause) the state transition. “Deliver Order” is one of them.

Note that there can be multiple events that cause transition between the two states. If you modify the example above as follows…

uml statechart double transition

You can document that either the customer, or the supplier (of the products for the order) can cancel the order.

There are two failings of the UML statechart. The first is the lack of support for rule discovery, and the second is that it is a poor framework for trying to document the business rules for later consumption.

State Transition Tables

You will have already created a state transition table as part of validating the completeness of your UML statechart. This is how the lack of support for rule discovery was addressed.

state transition table

[larger image]

In the comparison of UML statecharts with use cases, we made a small reference to documentation of business rules.

Each possible transition has a number – which provides a reference for defining the business rules associated with each transition. You could put the rules inside the boxes, but the numbers make the table much easier to read.

In this example, #3 represents the allowed transition of the customer-order object from the state of Placed to the state of Charged.

What You Need To Document

To document the business rules associated with a UML statechart, there are five elements that must be documented.

  1. Defining The Object. The definition and relevance of the object being described.
  2. Listing The States. The list of possible states that the object can be in.
  3. Defining The Rules of State. The rules that in force when an object is in a single state.
  4. Listing The Transitions. The list of allowed state transitions that the object can make.
  5. Defining The Transition Rules. The rules that govern the transitions from one state to another.

Defining The Object

A definition of the object is important to establish the context in which the business rules are being applied. Remember that this is a business object (a customer-order), not an implementation detail (class CustomerOrder :: Object). The description of the object and rules that define it will be in the language of the business, not implementation details.

Listing The States

You already have the list of states explicitly in the state transition table, and you could create it from the UML statechart. If you only had to list the different states, there would not be any value to creating an additional list – just reference the table.

Defining The Rules of State

Each state that the object can be in has a set of business rules associated with it. These are rules in addition to the rules that define the allowable transitions (more details below). Here are some example business rules of state.

  • Suppliers can view orders that are in the Charged or later states.
  • Suppliers can only view orders that include products that they supply.
  • Customers can edit orders that are in the saved state.

Listing The Transitions

The allowable transitions are implicitly defined in the state transition table. Each allowable transition has a reference number (or ID) in the table. Every transition is also displayed in the UML statechart. If there were no rules associated with the allowable transitions, the table could have been done with yes/no boxes instead of references.

Defining The Transition Rules

Each allowable transition will have some rules associated with it. What initiates the transition? What constrains the transition? Here are some example business rules that govern the transitions from one state to another.

  • An order will only be shipped when it can be completely fulfilled.
  • An order will not be charged unless the customer has provided a valid shipping address.
  • Orders will only be charged when the shipping address is in the United States of America.
  • A charged order will be cancelled if it has not been shipped within ten business days.
  • A saved order will be deleted if it has not been submitted within 90 days.

These business rules are important to the company. It is important to document them.

Scott Ambler shows a way to include this information within the UML statechart. His Figure 1 example demonstrates how to do it for object oriented design (the implementation design) and includes references to java functions that may be called. The concept could be applied to OOA diagrams as well.

We would encourage you to not include the rules within the diagram, as practicioners of Scott’s own advice – “I prefer to follow the AM practices Depict Models Simply and Model in Small Increments.” The extra information in the diagram makes it unwieldy. In our experience, a concise diagram with accompanying text is a better communication vehicle than a standalone diagram with higher information density.

Practical Application of This Approach

There are many systems for documenting and managing requirements and business rules. Forrester and The Gartner Group have even changed the name of the space from “Requirements Management (RM)” to “Requirements Documentation and Management (RDM)” in their communications. Generally, the solutions in the RDM space either use a repository to store information in a structured format, or they manage individual documents as artifacts.

Individual Document Approach

When your team is using individual documents to manage requirements, we suggest that you create a single text document that includes the text descriptions of states, transitions, and rules. This document should also include the UML statechart and the state transition table. These objects can be embedded or referenced to prevent the dual-maintenance problem of updating the text “wrapper” document whenever the underlying object changes. When using Microsoft Office, a Word document can include both the Visio and Excel objects by reference. HTML documentation will include the objects by reference. There is no really “clean” way to manage individual documents, and certainly no standard way to do it. Whatever works for you should continue to work. The goal is to present a single document (the “wrapper”) that contains or references all of the relevant information – prose + UML statechart + state transition table.

Requirements Repository Approach

If you have a repository that has been customized to specifically deal with UML statecharts, transition tables, and supporting rules, you’re ahead of the game. Please tell us about it too. As far as we know – it doesn’t exist.

Most structured RDM tools allow users to attach files to “requirements” objects. They also allow for the notion of supported and supporting “requirements” – either through traceability or composition. In the rest of this explanation, the term “requirement” is a reference to whatever artifact, object, or container the particular RDM tool uses to encapsulate a discrete business requirement or rule.

You can create a requirement that represents the business object and includes the contextual information describing the object (customer-order in this example). The list of states that the object can be in should be included in this requirement.

In support of that requirement, you should create other requirements that represent the defined business rules (#3 and #5 in the list) as separate objects. You separate the objects so that each requirement is atomic. The UML statechart and state transition table should be attached to the “wrapper” requirement as references. The diagrams, in this approach, are providing clarifying but redundant information. They need to be identified as such, so that in the event of misinterpretation (or requirements becoming out of sync), there is a clear “winner.”

Summary

There are many business rules associated with a business object that can change state. Those rules define the interpretation and ramifaction of being in a state. They also constrain and enable the transitions between states. The list of states and possible transitions are also business rules of a sort – although they may be better described as decision services than business rules.

Documenting these rules is important. You shouldn’t try and cram the documentation inside the diagram or the table. You should use accompanying prose.

CMMI Levels and Requirements Management Maturity Introduction

Five Levels

Welcome Readers of the Carnival of Enterprise Architecture! We hope you enjoy this series of articles!

CMMI (Capability Maturity Model Integration) is a description of the level of enlightenment of a process. It is essentially a measure of the quality and capability of a process. There are five categories, into one of which every process will fall. IBM took a similar approach to defining the requirements management process. In this series of posts, we will marry the two frameworks.

Background on CMMI Levels

We wrote an introduction to CMMI levels last March. In our article, we identified that there are five CMMI levels. Technically, there are six CMMI levels, when you include level zero. Level 0 is “undefined” by the CMMI, and represents an ad hoc process, or a lack of process.

CMMI Levels

  • CMMI Level 0. Undefined. No real process.
  • CMMI Level 1. Performed. A process is defined, but disorganized.
  • CMMI Level 2. Managed. A defined process is managed.
  • CMMI Level 3. Defined. A managed process is standardized across the company.
  • CMMI Level 4. Quantitatively Measured. The performance of a standardized process is measured.
  • CMMI Level 5. Optimizing. Performance measurement is used as a feedback loop to improve the process.

Take CMMI Levels With A Grain of Salt

Salt Shaker

Just knowing the CMMI Level of a process is not enough to know if the process is any good. By the same token, choosing a particular CMMI level, and meeting the technical requirements of that level are not enough to assure a good process.

Backgroundon RMM Levels

The folks at IBM wrote an article in 2003, where they defined five levels of maturity for requirements management processes. All five of the requirements management maturity (RMM) levels all build on the previous level, with increasing capability.

  • RMM Level 0. Chaos. No persistent documentation of requirements.
  • RMM Level 1. Written Requirements. Writing requirements documents (not emails and whiteboards).
  • RMM Level 2. Organized Requirements. Colocation, versioning, consistent formatting.
  • RMM Level 3. Structured Requirements. Defining types of requirements and their relationships.
  • RMM Level 4. Traced Requirements. Explicitly mapping the support-network of requirements.
  • RMM Level 5. Integrated Requirements. Integrating with the development environment and change management.

What IBM Didn’t Do

They didn’t map their framework back into the CMMI framework (known as CMM at the time) except for the following comment in the introduction of their article:

Those familiar with the CMM (Capability Maturity Model) from the Software Engineering Institute (SEI) will note some similarities to our parallel model, which has no direct relationship to the CMM save one: Achieving Level Five of the RMM will assuredly help an organization get to at least Level Three of the CMM.

IBM put together a great framework for describing elements of increasingly capable requirements management processes.

That is what the SEI tried to do when they developed the CMMI. Why couldn’t the IBM team just map their framework into the CMMI framework?

The problem is there is a mismatch between the two frameworks.

  • The RMM framework describes steps and elements of a requirements management process. Each step adds a level of capability to the process. It might be more aptly named the requirements management capability framework.
  • The CMMI framework describes the strategic capabilities (maturity) of how a process is applied, without assessing the tactical capabilities of the process itself.

The SEI recognized that the analysis of the tactical capabilities of any process would be different for every process, and left it to others to perform that work. This is almost what the IBM team did. We’re going to take a crack at it here.

Mapping RMM Levels to CMMI Levels

This is the first in a series of articles that will present a mapping of RMM levels to CMMI levels. We like using CMMI as a means to evaluate our internal processes, notwithstanding the challenges we mentioned earlier. We also like the framework that IBM presented for describing requirements management processes.

Shoot First, Ask Questions Later

There’s a lot more to write about this than we can put into a single article. We’re going to tackle this as a series. Even so, we put together an initial draft of how we think this will ultimately work out. We’ll share that here now. But we reserve the right to fix it when we find problems as we (and you!) put more effort into it.

CMMI to RMM Mapping
(larger version)

Articles In This Series

2007 – The Year of the Business Analyst

champion

Outsourcing is gaining momentum not only as a way to reduce costs, but as a way to create global teams. This trend is driving an increase in demand for business analysts. The change in perspective is driving companies to think about how they manage their business in new ways, and driving interest in new tools for business analysts to achieve these goals.

Hat tip to Ryan for his article on the year of the BA. The source that Ryan found is this yahoo article on 7 trends for 2007.

Trends

The role of the business analyst has emerged as a focal point for enterprises trying to wring more out of their automation-technology investments.[…] Ironically, outsourcing is feeding a frenzy to bring aboard more analysts. The experience of outsourcing IT has taught firms their technology-project specifications were in much worse shape than they believed. When companies would deliver specs to outside firms and individuals who didn’t have deep experience with their existing automation solutions, the knowledge gaps became painfully apparent.

Neal McWhorter, in the Yahoo article (emphasis ours)

We’ve all talked about outsourcing, and many of us have designed teams with different collaboration models to address the communication challenges.

This Computerworld article suggests that business analysts are one of 5 top areas for hiring, and business process management is one of 5 top technologies being explored.

How Business Analysts Adapt

Neal suggests that BAs will evolve their role and responsibilities to be something analogous to a product manager. We’ve been treating the roles similarly here – with the primary distinction being a single-customer focus for business analysts.

Neal mentions the IIBA and their new certification program as a likely means of setting expectations of and for business analysts. Barbara writes about the upcoming certification schedule for 2007.

Tools

We can’t overemphasize the need to be good at writing requirements first, and then using tools to become more efficient second. With that said, the increasing importance of business analysts drives the increasing importance of helping BAs be more effective.

Two areas where there are huge opportunities for improvement are business process modeling and requirements gathering/management.

BPMN

There are tools and vendors for BPMN solutions, and it looks like training is finally going to be more available in 2007. Bruce Silver is developing training that uses ITP Commerce as a tool provider. We’re currently designing a training course as well, built by extending the tutorial series we wrote last year, using visio stencils and a vendor-agnostic approach.

Requirements Management Software

Today, the space can be characterized as having the following solutions available:

  • Spend a lot on an enterprise package, and mandate that all your projects use it, in order to recover the costs.
  • Build your own solution, using spreadsheets, documents, email and other tools.

We expect this to change in 2007 too. Both of the approaches above can be cost ineffective for single-projects within a large company, SMBs looking to become more effective, and small consulting shops providing services to other firms. There’s a lot of opportunity here for the right solution.

Conclusion

Is it the year of the business analyst? The need is indisputable. Will the C-level execs act on it?

Building the Case for Requirements Management Tools

Movie Projector

Marcus Ting-A-Kee has assembled a great presentation on the value to his company of requirements management tools. In addition to creating the presentation and sharing it with all of us, he shares the process of creating the presentation in several articles.

The Final Product

Marcus made his presentation available to us via his esnip account (v 1.2 is the one I reviewed). Even if you aren’t interested in the genesis of the presentation, you should get it and read it. And if you don’t care about pitching for requirements management tools, you want to get the presentation anyway – it is a fantastic real-world example of many of the Beyond Bullets and Presentation Zen techniques.

Marcus’ effective use of imagery is the reason we have images with our articles. So effective on his site that we couldn’t pass them up here. I’ve been learning from him ever since – and in the presentation – even more and better use. Images supplant text, instead of just augmenting it.

The Approach

Marcus does it exactly right – he develops an understanding of his audience, including their goals, needs, and backgrounds. Then he designs a presentation to show how their goals are addressed, in a language that is consistent with their backgrounds – he adapts to the context of the listener. Awesome. Then he iterates and builds out the presentation.

Targeting his communication for his audience makes more of a difference than anything. Funny how few people do it.

The Genesys

Check out Marcus’ work and progress via his articles:

Conclusion

Marcus creates better presentations than we do. Maybe next time we can get him to videotape it – he probably delivers them better too. Thanks for sharing this stuff with us!

Companies Will Waste $1B This Year on Software Tools

drain

We are collectively flushing the money down the drain.

Gartner reported that companies spent $3.7 Billion USD on application development tools in 2004, with a 5% annual growth rate. The Standish Group has shown that 40% to 60% of project failures are due to requirements failures. At least 1/3 of the money spent on getting more efficient at coding is being wasted – it should be spent on writing the right software.

Background

Joe Marasco, CEO of Ravenflow, has written an article where he posits that we’re making bad investment decisions when it comes to improving our ability to create successful software. He’s provided data to support is argument.

The Standish Group, in their CHAOS reports has shown dismal software project success rates for the past decade. Digging into the details reveals 40% to 60% of the problems are caused by bad requirements.

Even when we know the problem is with our requirements, we also know that requirements management software will not solve the problem.

Problem Validation

Joe has the brilliant insight to recognize that with three CHAOS reports, we can produce a graph that shows a (possible) linear trend in improvement of a little over 1.5% per year in software project failure rates.

linear failure rate change

With roughly $250 Billion being spent on software projects per year, we are collectively seeing just over $4B in savings per year. Not a very good ROI for our projected $4B investment.

What if the linear assumption is wrong? We know half of the problems come from bad requirements, so there should be a limit to what improved coding efficiency can do. The graph may look more like this.

asymptotic curve approaching 50%

In that case, we’re about to have a negative ROI. Investment keeps going up, and results keep getting smaller.

Lies and Damn Lies

Joe asks “why so little improvement per year?” and raises an interesting point. Perhaps we are solving harder problems and achieving more value with fewer resources as we get more efficient at software. There is no way to reach an empirical conclusion on this, but we think he’s right – we are doing that. But we also think the law of diminishing returns makes the asymptotic curve more likely than the linear.

Engineers and Artisans

One reason that we are not improving faster is that software engineering is not engineering. [I say this as a former registered professional engineer]. Software engineering is requirements + code + test. Only coding and testing have elements of engineering in them. Requirements managers are artisans.
Software developers are making progress in abstraction and re-use. We don’t write in assembler any more. We have code libraries available to minimize reinvention, even in higher level languages. Software developers are becoming more like engineers every day as their behavior becomes more an element of applying existing code than writing new code.

Requirements writers bear no resemblance to engineers. Like carpenters hand-crafting furniture, we have little or no reuse in our process. We are artisans. Since we are addressing a “new” problem with each project, we may always have to approach things as artisans.

Becoming Better at Requirements

We’ve shown before that having better tools for managing requirements won’t improve the quality of the requirements any more than a better saw improves the quality of a custom cabinet. Faster and easier, yes. But not better. Artisans improve with training and experience. This approach makes sense as the best one for improving at writing requirements.

Over the last month, we’ve written a series of 10 articles targeted at writing better requirements. The focus of this series is specifically on improving MRDs, and the linked article contains the summary of all ten, as well as links to the individual articles. Topics like removing ambiguity, validating the content with stakeholders, confirming feasibility with development – all key to preventing errors.

Conclusion

We should be investing more of our time improving our ability to write requirements, and write the right requirements. Maybe we spend so much on becoming more efficient at writing code because we know how to do that.

A plant manager can easily rationalize spending money to make his assembly line run faster. He understands the problem, and can measure the results.

$4 Billion dollars are being spent trying to solve half the problem. Imagine what would happen if we took just 25% of that, and spent it trying to solve the other half of the problem?

In fairness, our industry isn’t ready to absorb that kind of investment yet, so we shouldn’t make such a dramatic shift.  How about 2%?

Gartner research on Agile Requirements Definition and Management (RDM)

magnifier

Gartner has a research report available for $95, titled Agile Requirements Definition and Management Will Benefit Application Development (report #G00126310 Apr 2005). The report is 7 pages long and makes an interesting read. Gartner makes a set of predictions for 2009 about requirements definition and management (RDM) systems, and the software created with RDM tools. Gartner misattributes several benefits of good process to RDM tools. We give them a 3.5/7 for their analysis – check out the details here.

Here’s the excerpt from their website (AD = application development):

The flexibility with which requirements are gathered and managed shows how disciplined an AD process is. AD organizations with automated requirements definition and management environments will better support change control, gain testing efficiencies and reduce future maintenance burdens.

Gartner Predictions

  • The cost of quality for developed systems will drop by 30%
  • Maintenance costs will drop by 10%
  • User satisfaction will go up from ‘fair’ to ‘good’ for medium and large applications

RDM systems have a meager impact on these predictions – other trends and processes are just as likely to affect them, hence our low rating of the Gartner report. Read on to see where they err.

Reduced cost of quality (RDM score 2/3)

Better requirements lead to fewer bugs. In Where bugs come from, we talk about the introduction of bugs from different sources in the process. The area where RDM can help is with misinterpretation of requirements. A structured system makes it easier to validate the alignment of proposed designs with requirements. RDM score = 1/1.

Incremental delivery processes will likely have a greater impact on cost of quality, as they help us correct mistakes in requirements documentation. This source of bugs (doing the wrong thing right) is higher up in the process, and thus has a larger impact on the bottom line. Gartner touches on this trend as well, but does not try to tease out the potential benefits and isolate them from the “benefits of RDM” analysis they present. RDM score = 0/1.

Traceability in RDM tools can provide large benefits in the cost of quality. To achieve these savings, RDM users must trace their testing to the requirements. This traceability helps uncover gaps in test coverage of the requirements, resulting in fewer bugs released to the field. RDM score 1/1.

Maintenance costs will drop (RDM score 1.5/3)

There are three trends that can drive lower maintenance costs for software. RDM can reasonably play a role in 1.5 of the 3.

  1. Improved design and implementation. RDM doesn’t make design better. Incremental construction creates opportunities for refactoring the code. RDM score = 0/1.
  2. Fewer gratuitous features. Most software today has too many features. Optimizing the features for a product will reduce the size of the code, and therefore reduce costs. RDM provides traceability of features to top level objectives (ROI), making it easier to identify and descope marginal features. RDM score = 0.5/1.
  3. Cheaper labor. Outsourcing can reduce the cost of development labor, but not as much as you might think. Joel Spolsky shows us that 80% of the costs aren’t programmers, so the upper bound on savings is small. Tarun Upadhyay provides some real world data showing that the total cost savings can be between 8% and 38% when replacing 70% of US developers with Indian developers. The extra savings comes from moving some of the abstraction layer (supporting roles and overhead costs) to India as well. RDM makes this possible by providing a means for rigorous asynchronous communication between team members operating in different time zones. RDM score = 1

User satisfaction will rise (RDM score 0/1)

User satisfaction is ultimately increased when software is focused on user task-accomplishment, or goal-achievement. Process approaches like Alan Cooper’s interaction design process make this more likely to happen. Existing RDM products use a structured-requirements representation, most aligned with Karl Wiegers’ framework. With Wiegers, the main tool for capturing user tasks is the formal use case.

While it is possible to combine interaction design and structured requirements processes, none of the current RDM products do this. Our prediction – none of them will make this change in time to impact Gartner’s predictions. As interaction design gains momentum in the product management space, customer satisfaction will definitely go up. But it will be in spite of RDM systems, not because of them. RDM score = 0

Conclusion (RDM score 3.5/7)

The optimism about improved economics of software development and improved levels of user satisfaction is heartening. Unfortunately, Gartner has tied too much of this optimism to the proliferation of RDM systems (they also forecast strong growth in sales of RDM systems). We pointed out that requirements management software will not solve the problems with bad processes.

We are excited to see Gartner focus on RDM and on RAD processes. Executives are very swayed by Gartner opinions. If RDM retools to support interaction design, it could indeed live up to these predictions.

Persona Grata

Different strokes cast

Different people approach the same goal very differently. When we don’t truly identify our users, we end up with software that dehumanizes, waters-down, and otherwise fails to succeed at anything more than grudgingly tolerated functionality. Even worse, we may ignore the needs of our key demographic, resulting in software failure. When we use personas instead of generic use cases, we can avoid both the misery of a failed product and mediocrity of marginal success.

Different Strokes for Different Folks

James Kalbach has a post at Boxes and Arrows about how to design for the four different modes of seeking information. This makes for a great analogy to how different people will approach the “same” task differently. All of these examples can be generically classified as “User searches for information on the internet”

  1. Searching for information about a known item. Imagine that you know a bunch about growing chile peppers. You want to learn the specifics of how to grow a habanero plant in Zone 3 of North America. You know what to look for, you know what terms to use to look for information. You know what questions to ask, you just need answers.
  2. Exploring an area of knowledge. You are tired of your job, and you want to find out if starting your own franchise business is a good idea. You have a reasonable idea of a starting point and general questions, but no idea what detailed questions to ask.
  3. Not sure what you even need to know. You decide to invest in a vacation property. You have no idea what you need to understand in order to know what questions to even ask.
  4. Repeat searches. Two years ago you learned about what it means when the yield curve inverts. Now that it’s time to rebalance your portfolio, you need to refresh your understanding of macro-economics.

Each of these examples represents a distinctly different user goal, even though they are all users of the same search software, and they are all searching for information. The same solution is unlikely to be ideal for all of them.

Personas for Requirements Management Software

Consider requirements management software and the users that are forced to live with it (most of us). Only enterprise software is consistently more obtuse about the notion of different users requiring different interfaces. RM software like Caliber RM, DOORS, RequisitePro and their ilk all suffer from the design specifications of myopic requirements experts. They suffer from other things too – featuritis, failing to clear the suck threshold, and an expert-only interface.

Requirements management software is intended to be not only a central repository for documenting requirements, but to be a dynamic hub of information. Everyone on the team should be able to use the system and consume information from it. When the software is designed for a single user (the requirements manager who inputs and manages the data), it makes it harder for other users to isolate the information that is relevant to them. An RM system is designed both for input and output, and where the major systems consistently drop the ball is in output.

Let’s look at three of the personas who need to consume status information that comes out of a requirements management system. We’ll start with their roles and their corporate goals

  • Program Manager. Responsible for the management of the requirements for a software application.
  • Development Manager. Responsible for delivering the functionality required to support each requirement in each release of the software. Also responsible for growing the development team’s capabilities.
  • Project sponsor. Responsible for delivering increased sales across every channel in every region the company serves. Funded the project.

Progam Manager – Joe K.

Joe K

Joe has been with the company for two years, ever since the startup he was at was acquired. He has a passion for driving new product innovations, has friends all over silicon valley and knows the latest ideas being explored by the current wave of startups. He’s driven some real innovation in embedded software development before. This is his first project with a user interface. Joe competes in an ultimate frisbee league every weekend, to burn off the energy he builds up with late nights at work. Joe’s biggest challenge isn’t getting the work done, it’s determining which work to do – he’s bursting with ideas. When Joe looks at the status of the product, he’s concerned that the dev team is hitting or will hit all of the releases. When they have to change the schedule, Joe works with the stakeholders to reprioritize and works with the development manager to find out what can be done.

Development Manager – Thom Jai
Thom Jai

Thom is all but burnt out. He’s managing development for two products right now, and both teams are global, with people down the hall and people on the other side of the planet. When he’s not trying to meet deadlines, he’s trying to figure out how to scale the offshore operations to save the company money. Thom has a family at home, and the midnight conference calls are really starting to frustrate him. He can’t cancel them, because his developers always have questions about what to implement, and he has no time in the schedule to let anyone lose a day while he waits to get an answer to a question. He has to interpret the requirements for his developers and provide them with context, clarification, and design suggestions. Maybe next month he’ll be able to work on performance reviews. When Thom is looking at the status of the product, he is trying to make sure that requirements aren’t changing after they’ve been scoped or scheduled. He also wants to know whenever the schedule changes for a requirement, or anything that the requirement depends on.

Project Sponsor – Julie Rogers
Julie Rogers

Julie manages a two-hundred person global service operation. Julie quickly rose up the sales-management ranks because of her ability to create strategic relationships with her clients. Every account she ever signed is still a customer. Julie contacts a different customer every week just to ‘check in’ and make sure the customer is happy. Her managers told her that their number one problem in closing more deals is getting the right prices for the products. Julie commissioned the IT department to build her software that helps her regional managers set the right prices for the company’s products. The IT team promised to deliver an application that could report on historical prices by the end of the quarter. By the end of the year, the application will even provide profit information, lead-time data (another big problem), and the ability to review customer-history when closing a deal. Julie’s daughter is in high school and applying to colleges across the country. Julie is spending every minute she can helping her daughter when she isn’t running her sales organization. She wants updates on the status of the project, but does not care about the details – “it’s like making sausage” is her favorite quote. She knows what her team needs, and she knows what Joe has committed to deliver.

Different roles, different goals

Each of our personas has very different goals. Joe wants to deliver the most valuable requirements as fast as possible. Thom wants to make sure the ground doesn’t shift beneath his feet – he’s busy enough making sure his team can execute to meet their commitments. Julie wants to increase sales, and believes the software will help, once it’s been deployed to her team.

Persona non gratis

If we ignore the different needs of our different users, we can use the same (and only) interface for all of our user tasks.

Julie will look at the schedule for the top-level goals in the system. Joe has explained that all of the structured requirements in the system roll up to those goals, so she can ignore everything else. Julie is immediately overwhelmed with information, but with some coaching is able to ignore the noise and focus on the signal (the scheduled dates for the goals). She’s content that everything appears to be ok. What Julie doesn’t realize is that the underlying requirements for one of her main goals has slipped by a release, and the date for the goal hasn’t been updated. She would not be able to work through the traceability matrix in the application to find the problem.

Thom is struggling – every morning he sees that at least a dozen requirements for the current release have changed. He has to keep an archived version of the SRS and compare the two files to see which changes are irrelevant (typos, etc), and which ones affect his scoping, or change functionality after it’s been implemented. Thom can use the interface, but it’s yet another complex system that he doesn’t have time to learn. He’s frustrated that he has to spend any time at all doing it, and especially frustrated that the one thing he needs the most (to understand what has changed, at a detail level) has to be done manually by him.

Joe is snug as a bug in a rug. The software works just like he expects it to work. Sure some steps are manual and tedious, but hey – managing requirements is hard work. Since Joe spends so much time in the application, all of the traceability is intuitive, he knows where everything is, and he’s even learned the shortcut keys for jumping around and mass updating of files. Joe doesn’t spend any cycles thinking about the UI, because it was designed for him – he gets to spend all of his time on his work.

Persona gratis

Just thinking about the problems from the perspective of our key users makes the problems glaringly obvious. Why didn’t the RM software vendors tackle these problems? Aren’t they supposed to be requirements experts? Shouldn’t they have an appreciation that a central tool for a team is used by more than one team member? They implemented row-level locking in the database to support multiple users (says so right in the press release). Shouldn’t they realize that the simultaneous use is by different people? Someone needs to hurry up and build a requirements management system that is designed for all of the people that use it. Or at least the most important ones.

We can learn from their mistakes

When we are gathering requirements, if we do it in the context of the user personas, we can create great software. Goal driven development is a great framework for doing this. When we keep things at an abstract level, we run the risk of making the software unusable by key users. It may not prevent a sale, but it certainly jeopardizes a renewal or future sale.

Requirements Management Software Will Not Solve the Problem

Norm Abram

Requirements management software will not solve our requirements problems.

Jerry Aubin of Seilevel made this great point in his presentation this evening at the IEEE Computer Society, Austin / A-SPIN event. This was a great event, focusing on how to take requirements management “to the next level” – not just being good at it, but being great at it. Seilevel’s speakers (Jerry and Joe Shideler) demonstrated that they have great insights into the art and science of requirements management – and presented some cutting edge ideas that extend the “known good ideas” in some interesting directions. Definitely a company to keep our eyes on and learn from. Their blog, requirements defined, is linked in our blog roll – check it out.

The Norm Abram analogy

Jerry used what he coins as the “Norm Abram analogy”. Norm Abram is a great carpenter, and he does a weekly television show here in the US. He has an amazing workshop, with every tool imaginable for cutting, shaping, sanding or finishing wood. And Norm uses those tools to create beautiful products.

If you had those tools, Jerry asked us, would you be able to suddenly create products as beautiful as Norm does?

No.

Norm became a great carpenter and he became proficient with tools that help him do his work faster. The tools didn’t make him better, they just make it easier for him to do the work.

Would having typewriters make us write better, or just faster?

Applied to requirements management

The same holds true about requirements management software. Having access to software won’t make us better at managing requirements. The software will help someone who already knows how to manage requirements be more efficient.

The folks at Seilevel have seen the introduction of RM software (requirements management software) actually be counter-productive for teams who are new to managing requirements. We agree – we think it’s like getting an expensive car so that we can teach someone how to drive. The learning process has to come first.

Jerry showed statistics from the Standish Group’s 2004 CHAOS report. We’ve talked about that report earlier. That report shows that 71% of software projects fail. The issue isn’t the speed or cost of writing requirements, the issue is writing bad requirements.

For those 71% – the problem isn’t the tool, it’s the training. For the other 29%, there are absolutely solutions to help us do our jobs faster.

What should we do?

There are two ways to get better requirements. Buying RM software is neither one of those.

  1. Get help with your requirements. Companies like Seilevel and Tyner Blain have already invested in learning how to do requirements right. Let them or someone else help you manage requirements, or let them do it for you.
  2. Learn how to manage your requirements. Get training, read, study, practice, fail, improve, and succeed. As individuals, find mentors. As companies – get outside experts to come in and audit your projects.

When should we buy RM software?

When we’re already good at writing and managing requirements, and we’re looking for a cost reduction. Introducing a tool of this complexity to a team that isn’t accustomed to the process will actually hinder the process.

iRise – software prototyping tool

irise logo

We received a comment from Tom Humbarger at iRise on an earlier post, which led us to take a look at their site.

iRise provides a tool for rapid prototyping of web-based applications, and there’s an overview of the products available. They have iRise Studio which allows people to create interactive prototypes of web-based applications, and iRise Reader that allows people to interact with their prototypes.

This is a good news, bad news, good news (at the end) situation.

The good news – they have an innovative idea – use prototypes to communicate requirements.

The bad news – Our initial excitement about their product quickly turned to skepticism while reading their copy…

Who are the target users?

iRise Studio is a powerful, easy-to- use application definition solution used by business experts to quickly assemble functionally rich simulations of Web-based applications in a matter of hours.

We are firm believers in the power of prototypes – especially when they can present a compelling vision for an application. The idea that a business expert can create a good one seems a little far fetched.

They’re going to do what?

Business people can quickly lay out the page flow of simulations and create high fidelity pages that precisely mimic not only the look and feel of the final application, but the business logic and data interactions as well.

OK, page flow of a mockup, maybe – but business people will not precisely mimic the look and feel of the final application. Even if they could – it would be a bad idea. We’ve talked about the imperative of not specifying implementation details as part of the requirements process. Specifying implementation details is one of our top ten use case mistakes.

The idea of doing the data modeling and business process simulation is cool. Lombardi Software, another Austin company does this stuff – but for enterprise clients. Some of the best people I’ve worked with are at Lombardi, I respect their opinions, and know that they are big fans of being able to do process modeling – and have it drive applications in the real world. If iRise has a comparable interface for modeling, it could be a great tool for rapid prototyping.

Why would they do that?

The interactive simulations can become visual contracts between business and IT, serving as stable blueprints for what to build.”

OK – now I’m getting concerned. Why is it a good idea to have non-experts specify the branding, layout, interaction design, and usability of a web-based application? Assuming that an expert business process modeler is at the helm, we can expect that high-level workflow is well designed. But the user experience? Show me a business expert who’s competent at designing interfaces and I’ll show you a switch-hitter currently occupying the chair of a business expert.

But we need a good prototyping tool!

The screenshots showing how the application is used to build prototypes look very cool. This application looks like a good product, but their marketing copy sure is targeted at doing the wrong thing. Check out the bits about modeling of scenarios too.
What about the testimonials? Maybe we’re missing something.

Here are some excerpts from the testimonials (note: we’re starting to get excited about the product again)

    • …allow us to rapidly and iteratively validate the client’s needs early in the process ensuring we have the right requirements from the start
    • to visually validate requirements and “test market” applications prior to investing time and money in development
    • can engage their business stakeholders early in the process to visually identify missing system requirements, eliminate unnecessary functionality and discuss important process and policy issues

    Yes, yes, and yes!

    This is exactly how a prototype should be used.

    What should iRise do?

    1. Change the way they propose that their clients use iRise. Business analysts, while ideally suited to identify, prioritize and validate requirements, are in no way suited to the designing of software solutions. User experience experts are. A picture is worth a thousand words, and an interactive prototype is worth a thousand pictures. Why risk misleading or dissatisfying the stakeholders with a bad prototype? Why prevent your development team from being able to apply their skills to design a solution? If you’re outsourcing to a development group with limited capabilities, this mindset might seem rational. The answer is to bring design resources in house, not ask non-designers to design.
    2. Find small consulting companies with a lot of passion for product success and a big megaphone (hint hint), give them a free copy of the software, in exchange for an honest assessment of how well it works and suggestions on how to incorporate it into effective software development processes.