Where is the value?

On a project that I worked on a few years ago, we were building a system for managing discounts and promotions on an ecommerce website for a Fortune 500 retailer. The system had two parts, a management system and full integration into the website so that the promotions would show up in the user's shopping cart.

The development team was small at 6 developers, but was part of a larger effort of about 50 developers. As we came up with the requirements, the development team selected WinForms as the technology so that the end users could get a better experience. They decided that they wanted multiple ways to access the management system functionality, similar to a standard Windows application. The application would have a menu bar, button bar and a side bar showing the objects with right click popup menus.

For an application that is going out to the general public, this potentially might be a great paradigm. In this particular case, I questioned the value as the user population of the management system was only 4 people who were creating the promotions and then managing them through the various lifecycle stages.

I demonstrated that the multiple menu options could not trace back to any business goals and that with even limited training, the users would know how to use the management system. Unfortunately I could not convince the team that this extra work was unnecessary. The client product manager felt that the user interface was "design" and thus should be left up to the development team. My interpretation of the situation is that the development team had several reasons for wanting to implement the functionality in this way: 1) They wanted to work with new technology; 2) They wanted to create a Windows style application as they had been exclusively writing Web applications; 3) They had plenty of bandwidth (by 3 or 4 developers).

What was the overall impact? The extended project team had incredibly tight deadlines and was actually understaffed. If we could have taken 3 or 4 developers from this team, we might have been able to add them to project teams that were in danger of not meeting their key functional requirements.

The final result was that while the promotions project was able to deploy, the extended project was put on hold and not implemented until just this year. I'm not saying that this one subproject caused the meltdown of the entire project, but I would say the development of functionality that did not map back to clearly defined business objectives across many subprojects absolutely contributed.

To close, I will leave you with a question, when was the last time you truly questioned the value of each of the requirements in your application?

Innovation, Design, and Requirements

About the same time I read Joe’s post Who’s the Designer—It Depends, I also read a great article by Geoffrey Moore on the Top 10 Innovation Myths. These two articles collided in my brain and gave me a new angle from which to explore Joe’s post.

Joe raises an interesting question: when writing requirements, should we describe the characteristics of a solution (pure requirements) or simply prescribe a specific solution (design)? He concludes that this is a business decision and the answer depends on the circumstances.

Moore’s Myth #3 is “It is good to innovate.” When discussing this myth, Moore points out that innovation in and of itself is not the goal. Innovation which leads to consequential product differentiation is the goal. Moore further notes that innovation which doesn’t lead to consequential product differentiation “…costs money and entails risk but does not create competitive advantage.”

The debunking of Myth #3 leads to an interesting corollary to Joe’s arguments. Pure requirements allow innovation. But, as Moore points out, innovation is not always a good thing. Therefore, when deciding where we need to land on the spectrum between pure requirements and design, one factor to consider is the potential benefit, or lack thereof, of innovation.

Moore gives us more to consider about where we want to land on the spectrum with respect to next generation products. When throwing light on Myth #1, “When innovation dies, it’s because the antibodies kill it,” Moore shows how legacy commitments to an existing customer base can derail innovation for next generation products. The decision to design, rather than write pure requirements, also limits innovation. Coupling these together in the form of a decision to design a next generation product may result in a virtual absence of innovation, leading to a lack of consequential product differentiation, resulting in the stagnation and eventual death of the product. Therefore, we should be cautious about falling too easily into the decision to simply design next generation products.

Joe’s question is always a tricky one. And, the answer is still “It depends.” But, Moore gives us a few more things to take into account when making that decision.

Who's the Designer? It Depends.

Requirements are constraints on the creativity of creative people. That sounds harsh, but it is true. Business owners and those that finance software projects don’t want just any system built – they want their system built. This means they have some preconceived notion on what the system has to do and, in many cases, how it does it.

The question then arises, how severe should the constraints be? How much interpretation should be left in the requirements for the developers and interface designers?

It depends.

An opinion I often see expressed is that you should specify the bare minimum of ‘design’ in the requirements. While I agree that this is true in a perfect world, it isn’t always possible given time and resource constraints.

Two approaches to specification are described by the diagram to the right. One approach, designated by the blue arrows, says that you should try and discover all of the true ‘requirements’ of the business. This will lead to a confined space wherein several different designs meet all of the requirements. Any of these designs, represented by the orange and green dots, will be acceptable to the users.

The benefit to this approach is that you are 100% sure your solution falls within the bounds of the business needs and it allows the creative team members to come up with some truly novel solutions in the software. This works extremely well when the problem is well-known but the solution is not understood well by the business.

The drawback to this approach is that it can take a great deal of time and effort. If even one requirement is missed, some aspect of the design may not satisfy the unspoken needs of the users and may therefore be unacceptable.

Another approach says that if the business knows what they want, you should capture that and describe it as well as you can. This is represented by the dots in the middle of the diagram. In this approach, the business knows their problem and they know how they’d like to solve it. This leads to a very detailed specification on what exactly the software will look like and do. You may not get the perfect design (represented by the orange dot), but you’ll probably get close (green dot).

The benefit here is that your specification will provide the users with a very clear understanding of the system and can provide a great deal of comfort to those that are footing the bill. Everyone can agree and sign off on something that gives a very clear picture of the future system. It also takes less time to describe a solution in this way.

The drawback here is that users often know what they want but don’t understand what they really need. By specifying the system in this way, you limit the creative choices available to the designers and developers and you may miss the mark completely (yellow dot) and produce something that doesn’t meet the requirements.

When do you use each of these approaches? They both have some utility. It all boils down to margin of error. If your margin of error is at or close to zero, there is probably only one design that will meet all of the requirements and your only safe bet is to use the first method to define the solution space. The interface designers can then have total latitude to design the software the way they see fit.

If, on the other hand, the solution space is quite large (e.g., users don’t really care that much about the implementation, they just want the broad functionality to be present), it can be much more efficient to use the second method and describe the system in as much detail as possible so it can be agreed upon before development begins. In this case, there really is no need for a dedicated design resource. Putting dollars into that effort is overkill.

So, what’s my opinion on who should ‘design’ the software? The answer is, as with almost anything else in the real world –

It depends.

Requirements Traceability

Traceability defined
I first was introduced to traceability years ago by Karl Wiegers in Software Requirements (First Edition) and was immediately sold on the impact it brings to a project. As important as it is, I noticed that few projects actually did it. I’m in a position now where I do apply it, and I find the basic fundamentals are still the same.

Traceability is nothing more than being able to define and track the relationship between two objects. Typically, there is a “derived from” relationship between the two objects, and you trace the link from the original item to the thing that was created from it (or vice versa).

Common traces
In software development, traceability provides a link within and between the objects that capture business needs, use cases, requirements, design, code, test cases, etc. For illustration, some common traces we see are between business needs and use cases, between use cases and requirements and within requirements to other requirements. In theory, you can also link from the requirements to the downstream software work products, such as design, code and tests, but I think it is significantly less common to see projects do that.



It goes both directions
There are two ways to trace - forwards and backwards. Forward traceability answers the question "What objects are derived from this object?” For example "What use cases address this need?" or “What requirements are impacted by changing this use case?” Backward traceability answers the question "Why is this object here?” For example "What use case makes this a requirement?" or “Why do we have this code?”

Why trace?
In deciding whether to trace or not to trace, it is important to understand the value behind it, because it can be time consuming. An appropriate approach is to think about the actual use cases for the traceability to understand what questions need to be answered on your project.

Here are some common suggested use cases for traceability. I’ve also captured the direction of tracing you need to accomplish each trace.

• Product manager needs to identify missing requirements (forward)
• Product manager needs to identify requirements that are out of scope (backward)
• Developer needs to determine what requirements are not coded yet (forward)
• Project manager needs to ensure developers are not putting development efforts into non-requirements (backward)
• QA needs to identify what requirements are not yet tested (forward)
• Developer needs to determine what code is impacted by a change in a requirement (forward)
• Product manager needs to determine what need is not met when a requirement cannot be developed (backward)
• Product manager needs to ensure there are no missing use cases that lead to missing requirements (backward then forward)
• Business sponsor needs to ensure all requirements are included in the release (forward)
  

If you need to be able to answer any of these questions, then it’s that simple, you should set up the appropriate tracing.

I need it, but now what?
To implement traceability on a project, it is important to start as soon as is possible in the project. Ideally the infrastructure will be put in place during the planning phase.

A few fundamental rules should to be followed for traceability to work:

• All elements to be traced must be labeled uniquely (UI Screen IDs, Use Case IDs, Requirement IDs, etc.)
• The team members must have time allocated to fill in the actual traces, each filling in the trace information for their respective artifacts
• The elements must each be clearly defined (with clean boundaries), so that there are obvious traces forward and backward
• If tracing from requirements to testing, the requirements must be testable

Tools
Traceability can be implemented with a variety of tools. Specialized requirements management tools make it easier to maintain and analyze the large number of traces that exist in any project of moderate or large size. Spreadsheets require a tremendous amount of manual effort, but they can be used when necessary.

One way to represent traceability in a spreadsheet is to do all traces in one matrix. In this traceability format, one object type is traced to many other object types. This will work best for simple tracing, where there is a one-to-one or one-to-many relationship to be analyzed. For example, in this case, the requirements are traced to test cases, and it is easy to see that there is a requirement that does not yet have a test case.

In the following table, I’ve added another column, to represent tracing from requirements to use cases. We are really only looking at the one-to-many relationship here of requirements to use cases (even though it is actually a many-to-many relationship), and therefore we can quickly see if there are requirements that do not map to use cases. However, in this view, it is challenging to see what use cases are missing requirements. If you set it up so that you can filter by each use case ID, then it will identify those holes more clearly.

Another way to easily represent this many-to-many trace in a spreadsheet is to do each trace in its own matrix. In this traceability format, you trace one object type to one other object type. If you want to do additional traces to other types of objects, you use a different matrix for each of those pairs. In this example, it is still easy to see that one requirement does not map to any use cases, but furthermore it is obvious that one use case appears to not have many requirements. That would be a trigger to look more closely at the use case to ensure a full set of requirements were captured for it.
Why traceability is valuable
Much of the value in doing traceability comes from the ability to identify holes – such as missed functionality or tests. Tracing also helps ensure you are building only the true requirements. Many organizations are not putting the effort into defining the traceability mappings during the requirements gathering phases, and therefore, are going beyond budget and timelines, or worse just deploying the wrong software.

Check back soon for a post on the different object types and their relationships used in requirements gathering!

Build Confidence with Prototypes

Go ahead and admit it — you write great requirements! You follow a solid process and create software requirement specifications that sparkle with stakeholder signoff. But if you’re like me, this is not enough. It’s a long way from SRS to deployment, and the myriad of design choices that happen in between can derail a strong set of requirements. How can you be sure that what goes live will really be successful?

As business analysts, we need to keep users focused on what they need, not how they need it to be done. When developing a software requirements specification, I like to imagine a system implemented with stone tablets and flying monkeys. In other words, the design should not matter during requirements development; let it be something crazy to make that as clear as possible to everyone involved.

Unfortunately, most people do not seem to think this way. Although they might not admit to prematurely thinking of design, internally they start building a picture of what the system should look like from day one. Sooner or later, we have to deal with these unspoken visual requirements. We can dramatically improve our chances of a successful project by modeling these requirements through iterative prototyping.

A prototype is a model or partial implementation of a system. Prototypes may take many different forms, ranging all the way from rough napkin sketches to fully interactive mock-ups of a user-interface. Each of these can be valuable. As Karl Wiegers says in Software Requirements (Second Edition), "Software prototyping makes the requirements more real, brings use cases to life, and closes gaps in your understanding of the requirements." Of course, some prototypes may be more effective than others given the circumstances of your project.

A Slice of Life
Prototypes can be categorized as either horizontal or vertical, based on the view that they take of the system. Horizontal prototypes model a shallow slice of the architecture. These are most often used to evaluate user-interface design. Vertical prototypes provide a proof of concept by modeling a deep slice of the system, from the front-end to the back-end. These are primarily used to evaluate technical feasibility of a proposed solution, or even provide a solid foundation for building the actual system.

To Keep or Not to Keep — That is the Question
Prototypes can also be classified as throwaway or evolutionary, depending on how long they are intended to be used. Throwaway prototypes, as the name implies, are short-lived, yet that does not diminish their potential value. They can usually be developed very quickly (at low cost) and help drive rapid user feedback. Examples of throwaway prototypes include screen mock-ups and storyboards, both of which can be developed with tools like Visio or simply pencil and paper. On the downside, these models stop short of allowing users to completely validate a potential solution. This is where evolutionary prototypes take over.

Evolutionary prototypes are functional systems that permit users to fully-evaluate the implementation. Unlike throwaway models, these are not intended to be short-lived. They ultimately should evolve into the final system through iterative incorporation of user feedback. The main drawback to evolutionary prototypes is that they take longer to develop (and incur a higher cost) than their throwaway counterparts.

Fortunately, prototype models can be combined for stellar results.

Pulling it All Together
The best way to build confidence in your requirements and drive project success is through use of all four prototype models that we have discussed. The process assumes that you have already created a first draft of the Software Requirements Specification (SRS) that includes use cases, functional/non-functional requirements, etc. This serves as the foundation for horizontal and vertical prototypes that will help refine and validate your work. The diagram below provides an overview of the process:

Horizontal Prototype
The User Experience (UX) team works with business analysts to produce the User-Interface Specification. At each step along the way, collect feedback and update the prototypes as necessary. The UX team should work with business analysts to update the SRS and/or User Interface Specification if refinements to the requirements have been identified.

1. The UX team uses throwaway screen-mockups to review potential UI implementations.


2. Once a general approach for the UI has been decided upon, the UX team produces a throwaway set of low-fidelity wireframes that represent a complete walk-through of the UI. In other words, all use cases should be addressed, and all screens in the system should be represented.




• The wireframes should show all interactive elements of the UI. For example, the wireframe for a billing details screen would include text fields for a customer’s address, but the wireframe would not include a static banner image for the form.


• Keep the wireframes in black and white, and use Lorem Ipsum text to keep users focused on workflow and requirements (not "look and feel" or real data). The wireframes are intended to help users visualize and validate the SRS.


• PowerPoint is well-suited for producing a set of wireframes. Do not waste time making the presentation interactive. Users should be able to easily understand the workflow by simply clicking from slide to slide.


• Consider exporting the presentation to HTML for easy accessibility to people who will be reviewing the wireframes.




3. Once the wireframes have been approved by stakeholders, the business analysts should develop interaction requirements for wireframe UI elements. For example, a requirement might be written that describes how the UI should behave when a given button is clicked. In some cases, simple text is sufficient to describe the interaction. If the UI is more complicated, you might consider using Click-Action-Response Tables.


4. Once the wireframes and interaction requirements have been approved by stakeholders, the UX team can transform the wireframes into a high-fidelity prototype of screenshots that describe the "final" UI design. All use cases should be addressed, and all screens in the system should be represented.




• Functionality implied by the screenshots must match the wireframes, but the screenshots include "look and feel". The screenshots set specific expectations for the user-interface between business owners and the development team.


• A tool like PhotoShop is great for producing the screenshots (with extensive use of layers to minimize maintenance). Like the wireframes, consider exporting the images to HTML for easy accessibility to reviewers. Users should be able to simply click from screen to screen. Photoshop PSD files can be given to developers for precise layout guidelines, and developers may even cut assets directly from the images.

Vertical Prototype
The development team produces an evolutionary prototype that ultimately becomes the delivered system. At each step along the way, collect feedback and update the prototype as necessary. Send feedback to the UX team. Work with business analysts to update the SRS and/or User Interface Specification if refinements to the requirements have been identified.

1. The development team uses throwaway vertical and horizontal prototypes to evaluate technical feasibility of various architectures.


2. Once a general approach for the architecture has been decided upon, the development team produces an evolutionary prototype with a limited set of functionality from the SRS. The UI is implemented in accordance with the wireframe deck.


3. The development team updates the prototype with additional functionality in accordance with the SRS. The UI is implemented in accordance with the wireframe deck and interaction requirements.


4. The development team updates the prototype with additional functionality in accordance with the SRS. The UI is implemented in accordance with the UI Specification (screenshots with interaction requirements).

Seeing is Believing
Developing a great Software Requirements Specification is a step in the right direction, but it’s not enough. First, develop a User Interface Specification to establish a clear expectation for visual design. Second, develop an evolutionary prototype to drive iterative end-user feedback. Both techniques can also help identify missing requirements, as well as refine existing requirements. Use prototypes to build confidence that your requirements will lead to a triumphant project success.

Legacy Migrations

We recently finished a project fully documenting a very large existing system. The ecosystem was made of about 30 applications working together and was obviously very complex. This is not unusual in large organizations. The goal of the project was to understand enough about the existing requirements of the system to completely replace the system.

This project was not unique by any means. Every Fortune 500 company that we have worked with has had a similar level of complexity in their IT systems. Here are some random thoughts about working with these very large legacy migrations.

1) Big bang migrations are incredibly difficult to make work. It is possible, but requires a lot of talented people to pull off. If you imagine that the ecosystem that you have today has had 20 years to mature with hundreds (or thousands) of small releases. In that time you can probably estimate the total number of severity one defects. Because the upgrades were released over time, the pain was spread out over 20 years. Now think about getting all that pain at once in a big bang release. It is still a challenge, but think about how you can slowly isolate and then replace pieces of applications.

2) Don't feel bad if you are lacking in documentation. Everyone we work with seems embarrassed that they dont have much in the way of requirements, business process, design or even user documentation. What they don't realize is that no one seems to have that documentation. I haven't figured out if maintaining the documentation is cost effective or not, my gut says that it is.

3) The people, systems, data model that we use really is comprehensive when trying to document one of these large legacy systems. Take a look at some of the blog posts below where we discuss the models and the overall people, systems, data concept.

4) Traceability to make sure you haven't missed anything is incredibly time consuming. The tools today are simply not sufficient. We need to be able to trace not only between requirements but between requirements and elements in visual models (flow charts, data flow diagrams etc).

5) Agile methods won't work on these projects. In fact for most of the projects we work on lack of planning is the biggest killer to the success of the project. Agile has a role on smaller projects. But when you are trying to coordinate 20-30 developers, having written plans and a very clear and detailed understanding of what is to be built is critical.

These were just some random thoughts I had about our experiences with these huge projects. I would love to discuss this further, so see you on the messageboard.

What Do We Do?

As referenced in the recent post from my colleague on the Seilevel sales team, our ongoing challenge is to articulate why anyone should hire us to help them with better requirements. If nearly 20 years of selling have taught me anything it is that if you can help a prospective customer see your solution in light of their own problems, you are one step closer to winning their business. This post is an attempt to help our prospective customers understand exactly what we do – and perhaps picture themselves in the scenario.

A couple of months ago we had recently launched a new look and feel for the Seilevel website. In the first version we purposely kept the content simple and to the point, with an underlying rule that there would be “no scrolling”. Keeping everything above the 600 pixel line helped with the billboard effect we were striving for, but the site was very text intensive and we needed more graphic elements to illustrate our services. Constrained by our small company marketing budget, but looking for the kind of visual diagram made famous by Xplane, we were forced to get creative.

Our talented local design partners were more than happy to take on this challenge – but numerous brainstorming and whiteboard sessions were not getting us any closer to what we thought would showcase our offering. Then, on a sales call one day a prospective customer described exactly the scenario we needed in our diagrams. We knew it was time to stop making it up, and just listen to what our customers were telling us.

Here’s the commonly occurring scenario we heard that day: The business users in an organization determine their objectives and describe what they are looking for to IT. The IT team spends time building the application based on what they heard and deliver back a product that doesn’t meet the business users’ expectations.

It’s a story as old as the software business itself. As we all know, even after the first CHAOS report in 1994 revealed that the top three causes of project failure are requirements related; things in 2006 aren’t all that much better. Even now, only 29% of software projects are successful.

At Seilevel, we know it doesn’t have to be that way. We determine what the stakeholders and application users really need, get business and IT on the same page and ensure that the requirements are defined clearly so the development team can build a product that truly meets the needs of the organization. That’s our definition of project success.

Unfortunately, Seilevel is not yet of a size and reputation that we get involved early enough or often enough. Often, by the time we get involved, our role is to try to get the train wreck back on the rails. When it comes to software projects, the attitude of many organizations seems to be analogous to our medical system – no funding is available for preventative care, but there are millions of dollars available to put the patient on life support when they slip into a coma.

An up front investment in requirements will pay off in software project success. And more time on requirements doesn’t add time to the overall project, as better requirements mean less time on development and less time on test. Less time equals less money.

So, please check out our new diagrams. And if you can picture yourself in the first scenario, maybe it’s time to give Seilevel a call and see if we can help you define success for your next software project.