Monthly Archives: November 2006

Skip The Requirements, Empower The Developers

Process Improvement, Requirements, Software development

stop sign

Enough of the debates about requirements and what we call them. Why don’t we just hire great developers and empower them to work directly with the customers?

Lost Garden

Danc, at Lost Garden has an article that asks just this question, and addresses the challenges of directly empowering developers.

A couple quotes to set the tone of their article:

What would happen if the developers possessed a deep understanding of their customers needs and desires? Suddenly, those thousand little decisions aren’t introducing random noise into the product. Instead, they are pushing the product forward.

And…

One philosophy is that we need better specs and those damned monkeys need to implement the specs exactly as designed. Better command and control system and more rigorous process is obviously the trick to success. This tends to generate poor results.

Getting Closer To The Customer

Danc offers these tips to help the developers get closer to their customers:

  • Use your own product
  • Onsite customers
  • Observe customers using your product
  • Hire psychologists and ethnologists to study your customers
  • Listen to lead users
  • Reduce feedback cycle time
  • Improve objectivity of results
  • Improve clarity of results

The only inconsistent point in his article seems to be the suggestion about using ethnologists. Don’t they present a barrier to developers in the same way that a product manager would by synthesizing and prioritizing “the voice of the customer?”

Freeing developers from a job where they are coding “to spec” will definitely empower the developers. I believe that having someone trained in prioritization and interpretation of needs (a product manager, for example) can help keep the team aligned on the important stuff by providing insight into what is important. This is the same argument for having “experts” interpret customer behaviors.

Check it out.

Abstraction And “Requirements”

Requirements

not dead horse

Roger had some good comments in our previous article – we’ll try and address one of his points here. His point, I believe, is that using the word “requirements” to describe multiple levels of abstraction in the definition of a product is a bad thing.

Part of Roger’s Comment

Hopefully, this is the main point, not taken out of context by me. Check out the Requirements Naming for full context.

My real point is that I don’t think it’s possible to reconcile all of the terminology (”market requirement”, “product requirement”, “functional requirement”, “nonfunctional requirement”, “software requirement”) associated with these documents.

I believe we agree that there are different levels of abstraction, and that they are valuable. Even smaller teams will benefit from a distinction between “where’s the value” and “how do we realize the value?” Roger also said:

I have no issue with two levels of documents, at least in theory. I just don’t see how you can reconcile the terminology.

Adjectives

I believe that adjectives act as sufficient modifiers to differentiate the applications of the term “requirement.” Roger argues that a linguist would search for names of things that are appropriate without causing confusion. His point, I believe, is that having the word “requirement” in both of the following names does irreconcilable harm : “product requirements document” and “software requirements specification.”

I think the re-use of the word is annoying, not harmful.

Abstraction

I believe there are some fundamental layers of abstraction that are critical to understand in order to achieve software product success.

  • What value are we trying to create?
  • What processes will people/systems follow to realize that value?
  • What capabilities and characteristics must the product include to enable people to follow those processes?
  • What design approach will be used to implement the capabilities with the required characteristics?

Different teams in different environments will formalize these elements differently. The decomposition approach from value to implementation is a good one – it separates different types of problem-solving and ideation in a way that makes the overall problem more tractable. Our article, Software Requirements – Process and Roles, takes a detailed look at precisely this point.

Naming The Abstractions

We could come up with terminology for each level of abstraction that do not re-use words. As my grandpa would have said, “You’re closing the barn-doors after the horses got out!” I believe it is pointless to try and re-name things that already have established names. There are millions of hits in Google alone for these terms. Our best bet is to try and share an understanding of what is intended by each name.

The issues around the naming of functional and non-functional requirements are different, as they are not variations in abstraction, but rather classification of elements at the same level of abstraction.

Non-Functional Requirements

There is value in maintaining the classification of non-functional requirements. Requirements that represent different aspects of what shall be done should be separated, but they should also be treated with equal importance.

  • Functional requirements define what the system must be able to do, without defining how this is to be accomplished. The system shall store contact information. The system shall apply shipping and tax charges when billing customers.
  • Non-functional requirements define measurable, characterizing aspects of what the system must be able to do. The system shall return search results in under ten seconds. The system shall process at least 10,000 orders per minute.

Non-Functional Requirements Equal Rights Amendment

These two types of requirements should be separated to assure atomicity of our requirements. This separation allows our developers to do things like deliver the functionality first, and improve the performance second. This benefit alone requires (hah!) us to treat them separately.

Using different names to classify these two types of mandates provides minimal value, sure. I believe it also does minimal damage. The benefit of having different modifiers (functional versus non-functional) is that it reminds us to write them differently. Some authors have distinguished these as “what” versus “how well.”

I also believe that the distinction between the two is well defined and understood in the context of “those things you write to assure that software enables use cases to be executed.” To the best of my knowledge, that is the only context in which the term is commonly used (aside from your questions in an earlier article on product requirements).

Conclusion

I don’t know how many of our readers have reached a conclusion to this debate, but we have for now. Thanks to everyone who has contributed to, enjoyed, or at least tolerated this ongoing discussion.

  • Different terminology exists for describing requirements at different levels of abstraction.
  • There are choices of documentation approaches to use at each level of abstraction (MRD or PRD, FRS or SRS).
  • Having the different levels of abstraction is valuable as an organizational approach to creating great software.
  • Functional and Non-functional requirements are different things with precise definitions in a single context.

Requirement Naming – Stick A Fork In It?

Requirements

Stick a fork in it
The discussion about requirements and the naming of things continues. Can we stick a fork in it already? Maybe, but probably not. Catch up on the cross-blog discussion with Roger and Adam. Long time readers may also remember the discussions that included Michael and Tony several months ago.

Recent Discussion

The latest round of discussion started with the following articles (and comments/questions from Roger):

Market Requirement Valuation Example

This is our market requirement.

Sole-proprietor restaurants will reduce the amount of food spoilage by 50%, by making better food purchasing decisions.

From Market Requirement to Product Requirement

The market requirement:

Sole-proprietor restaurants will reduce the amount of food spoilage by 50%, by making better food purchasing decisions.

Is addressed through two product requirements:

  1. The system shall reccommend ingredient purchase amounts and timing that would reduce spoilage by at least 50% against the baseline.
  2. The system shall allow users to ignore its reccommendations.

Requirements Context

Market and product requirements are both at the “Goal” level. [More detail in this article]. Use cases are used to convert a vision of how a product will exploit a market opportunity. Use cases describe how the product will be used. And functional requiremens enable communication between the business and the implementation team.

Valuable and Functional Requirements

Market requirements and product requirements can be characterized based on value, but are undefined along the functional/non-functional axis. The requirements that make up a specification can be classified as functional or non-functional. And these are the requirements that drive design. Design boundaries are defined by constraints.

Which inspired Adam to write a pretty strong critique of “big upfront requirements” (BUFR) from the startup perspective.

While I don’t discount the usefulness of this type of information, I’d drown if I had to write something like this. MRD, PRD, SRS, FRS — acronyms galore. […] This is just an observational post about how the start-up environment I’m in is so much different.

To which I responded with a long and rambling response.

And trust me when I say I share your concerns about the complexity and acronymity of the big company software development process. I think the situation has evolved as a result of mixing the bureaucracy of big companies with the need to delegate responsibility.

[…]

Requirements documents are all about communication. There’s a vision that someone sets for a product or project. When that person has direct, regular communication with the team that makes this product a reality, then the documentation approach will be very different than when a distributed team of fifty people are all three steps removed from the person with the vision.

Another factor is specialization. When a person has the opportunity to play multiple roles, she don’t need an artifact for communicating with herself. And the distinction between a product requirement, a software specification, and a high level design is academic. Her thought process should be focused on “is this a good idea?” not “am I putting design details into the specification?”

Which prompted Roger to respond.

I have been struggling to understand Scott’s requirements framework. My suspicion has always been that the MRD/PRD/FRS/SRS onslaught of documents:

1. Is harmful to organizations (startup or not) that produce them all.
2. Employs terminology (”requirement”, “functional”) in a logically inconsistent or highly inelegant fashion.
3. Reflects a substantive misunderstanding of requirements.

In short, I do not believe, as Scott states, that the distinctions are “academic”, even for a “vertical operator”.

[… more good stuff and a concrete example from Roger…]

But Scott isn’t your typical requirements analyst, which is why I look forward to his continuing the discussion I’ve started on his blog.

And Roger also posted an article including a conceptual model on his blog.
Summary To Date

Whew. Fun stuff, and a lot going on. There is a lot more going on in each of the posts and in the comments – I tried to tease two ideas.

  1. There are a bunch of requirements document formats. They all talk about requirements in different levels of detail. Roger says this is harmful, is logically inconsistent, and demonstrates a substantive misunderstanding of requirements.
  2. The distinctions reflected in the above are / are-not academic.

Document Formats and Abstraction

Yes, there are a bunch of different types of requirements documents in use today. Using all of them on one project is bad. We should use either the MRD or the PRD, combined with either an SRS or an FRS, to create a design. From that design, a solution is implemented. Roger is right – all of these documents should never be used on the same project.

Can any of these document types be completely eliminated? Is my “framework” suffering from the same problem as the vista shutdown featuritis? The different documents are designed to do different things, for different people. Each of those people can reasonably interpret the intent of the document to mean either what, why, or how, depending on their perspective. For the record, I am not proposing a “framework” that uses four levels of requirements documents plus a design. I use the word “or” quite a bit.
Requirements documents are intended to communicate. When a team is structured with horizontal contributors (read the comments on Adam’s article if you haven’t already), a horizontal decomposition is both justified and constructive. But two layers is sufficient – MRD/SRS or PRD/FRS. When team members have vertical skills, then a vision-statement combined with some prototypes may be more efficient.

The Naming Of Things

Naming is an outgrowth of context. A “requirement” is synonymous with “a reason why” we do something – because it is required. When people operate at different levels, the problem is being decomposed into different notions of why and what (and how). For any given person to describe their “why” as a requirement is not unreasonable.

“Reflects a substantive misunderstanding of requirements?” How about “Summarizes perspectives that are not my own?”

The usage of the word “requirement” is permanently entrenched in the vernacular and is overloaded with multiple meanings beyond the single meaning identified in Roger’s conceptual model. We’ll never escape or change this. Perhaps Roger and I disagree because he wants the word to only be used one way, and I want people to be aware of (and tolerant of) all the ways that people use the word.

Academic Distinction

The distinctions between product requirements, software specifications, and design are highly relevant to “horizontal” players. Roger is right about that.

Imagine a start-up team where the CEO creates the vision for a product and the lead engineer decides how it will actually be built. The distinction between the vision/requirements and the specification/design is also not academic (another point for Roger). The distinction, to that engineer between the specification and the design is academic (half a point deducted).

If the distinction between a spec and a design, when the same person is responsible for both, is not academic, then what is the benefit of putting them into separate documents? The documents are intended to communicate. Who would be communicating with whom? For a large (horizontal) team, it makes sense to have a document that allows a product manager to communicate with a lead engineer. Especially if the team is geographically distributed or outsourcing.

Conclusion

Small companies and large organizations operate differently. They staff projects with people who have different skill sets, and expect those people to deliver different things.

Requirements documents are intended to communicate. Different teams need different communication, and therefore different documentation approaches. One size does not fit all.

Subordinate and Superordinate Use Cases

Requirements, Requirements Models, Use Cases

pyramid

Use Cases can be built up by combining other use cases. When a use case is made up of other use cases, the component use cases are known as subordinate use cases. The “parent” use case is referred to as the superordinate use case. This is known as composition. See an example of how composition works for use cases.

Composition In Use Cases

One of our regulars was reading an early article on composite requirements, and wanted to know how to approach the same thing with use cases. In our earlier article, we showed how to use composition to organize related, possibly interdependent requirements to better manage delivery. We used composition to assure that each requirement remains atomic.

Since that time, we’ve proposed managing the delivery of software with use cases. We face the same challenge – delivering sufficiently valuable use cases (read: having a large enough scope), without building overly complex and redundant use cases. We also want to re-use use cases (or portions of use cases) when possible.

Cockburn On Sub Use Cases

Alistair Cockburn writes:

An action step can be a simple step or the name of another use case.

Writing Effective Use Cases

He goes on to explain that a single use case consists of multiple steps. Each step may be either a single step, or an entire use case. His article on use case fundamentals goes into a little more detail about subordinate use cases (the steps) and superordinate use cases (the combination).

Normal Use Case Example

Use Case: UC1: Perform Annual Car Maintenance

  1. Change the Oil
  2. Change the Brake Pads
  3. Wash the Car
  4. Renew State Inspection

Each step within UC1 is a simple step. This represents a normal formal use case.

Superordinate Use Case Sample

Use Case: UC1: Perform Annual Car Maintenance

  1. UC2: Change the Oil
  2. UC3: Change the Brake Pads
  3. Wash the Car
  4. Renew State Inspection

By identifying that the first two steps are actually other use cases, we have turned our normal use case into a superordinate use case.

Subordinate Use Case Sample

Use Case: UC3: Change the Brake Pads

  1. Purchase New Brake Pads
  2. Raise Car On Jack
  3. Remove Wheel
  4. Replace Pads
  5. Restore Wheel
  6. Lower Car
  7. Repeat Steps 2-6 on Other Wheels

This use case is a normal use case, but since it is also used within the superordinate use case (UC1: Perform Annual Car Maintenance), it is also a subordinate use case.

Benefits of Composite Use Cases

There are two main benefits of this approach. First, we leverage our documentation to maximize re-use. UC3: Change the Brake Pads can be done independently (for example, if the brakes start to squeal), or it can be done as part of the annual maintenance use case. We have only documented the use case in one place.

Second, we can communicate the delivery of our functionality as UC1: Perform Annual Car Maintenance, while managing the requirements and development of the subordinate use cases independently. This also helps with prioritization. The value of UC3 is more than just the value of performing UC3 when the brakes start to squeal – it is also the value of UC3 when performing our annual maintenance procedure. This helps assure that we do the most important stuff first.

Summary

Subordinate use cases are normal use cases that are re-used as steps within a superordinate use case. Re-use helps to reduce work while properly tracing and prioritizing.

Happy Birthday Tyner Blain!

Administrivia

beer

Hooray Us

We’re taking the day off to tip back a cold one and celebrate a great year as a community! Tip a glass with us, and thanks for being here!

History

Tyner Blain was formed in May 2005, and we started the blog on Nov 24th 2005. New to the whole blogging thing, we started out with a free site on WordPress, realized that we had an opportunity to create a great community, and moved everything to our own domain in January 2006.

Since then, we’ve published over 300 articles, covering topics throughout the software development life cycle, with a common theme – delivering software product success. We hope you’ve enjoyed them, and thanks to all who have contributed to the fantastic conversations that have started in the comments on many of the posts. We’re not going anywhere, and hope you aren’t either.
Your Favorite Posts

When we look back at the stats, here are the posts that have received the most page views:

  1. Top Ten Tips for Preventing Innovation (thanks to Scott Berkun for the super-powers of your link!)
  2. Software Testing Series: Black Box vs. White Box Testing (thanks Yahoo for sending several people here every day)
  3. Death By A Thousand Cuts – Usability Problems Add Up (thanks to the spam-bot that hit this page thousands of times in July)
  4. Foundation Series: Black Box and White Box Software Testing (Google and Yahoo combined to make this a winner – thanks guys)
  5. Top Five Requirements Gathering Tips (pure organics at play. thanks to everyone who’s linked to this page)
  6. Foundation Series: Structured Requirements (almost everyone who read this came to it to get background info in support of another article – proof that the Foundation Series idea is working)
  7. How to Use Timeboxes for Scheduling Software Delivery (thanks to Pragmatic Marketing for publishing an extended version of this one last month)
  8. Requirements Vs. Design – Which is Which And Why (Our standard-bearer in the great debate)
  9. Foundation Series: Business Process Modeling (We’ve had a lot of attention, both supporting and criticising our BPMN series)
  10. Requirements Document Proliferation (the first of our attempts to describe the way-too-many-different-ways to document requirements)

Thanks to everyone who has read, commented on, contributed to, inspired, linked to, criticised, or otherwise been involved in everything we do here. You can’t imagine how appreciated it has been, is, and will continue to be. Thank you!

International

The top 10 (of 170+) countries from which our visitors read Tyner Blain:

  1. United States of America ( 63%)
  2. Republic of Korea (3%)
  3. Brazil (2.7%)
  4. India (2.2%)
  5. United Kingdom (2.1%)
  6. Canada (1.9%)
  7. Taiwan (1.4%)
  8. Thailand (1.2%)
  9. Japan (1.1%)
  10. Germany (1%)

If you want your country to make it to the top ten for next year, spread the word :)

Big Numbers

The surprising and humbling stuff…

  • Global reach with readers from over 170 countries.
  • Over 300 links from other bloggers according to Technorati.
  • Over 400 comments from the awesome people who are part of our community.
  • Over 500 subscribers to our RSS Feed (as reported by Feedburner on weekdays), 70 by email (Feedblitz)
  • Over 500 file downloads (presentations and bpmn visio stencils)
  • Over 750,000 page views, from over 300,000 visitors, from just under 50,000 unique IP addresses. Wow. That’s insane.

ConclusionSome ridiculously low percentage of blogs die in the first year. We haven’t – thanks to you! We’re not going away any time soon, so stick around and enjoy the fun!

Fifteen Ways to Shut Down

Design, Interaction design, Prioritization, Requirements, Software development, Software requirements specification, UX

shutdown

[Updated Below] There are 15 ways for someone to shutdown a laptop running Windows Vista. This adds unwarranted complexity to our software. How can we avoid the same problem in our software?

Hat Tip

Joel (on Software) has an article where he lambastes the Vista team for providing 9 different ways to stop using the computer. Add in the hardware options on the laptop (like Fn F3), and closing the screen down or hitting the physical power button, and you get to 15 different ways to shut down.

Inevitably, you are going to think of a long list of intelligent, defensible reasons why each of these options is absolutely, positively essential. Don’t bother. I know. Each additional choice makes complete sense until you find yourself explaining to your uncle that he has to choose between 15 different ways to turn off a laptop.

Joel Spolsky

Make Everybody Nobody Happy

Joel posits that the unreasonable number has grown out of the desire to make everybody happy. We know that too many features makes everyone unhappy. This bloated list of choices is just one manifestation of too-many-features, and it doesn’t make anyone happy.

Inadvertantly Causing The Problem

It is pretty easy to imagine how we might inadvertantly cause this problem.

A structured requirements approach allows us to track and manage different requirements, as well as the implementation of those requirements. In Joel’s example, imagine requirements like the following:

  • User secure the computer in order to walk away from it without other people getting access.
  • User can shut down the computer such that it will stop consuming power.
  • The computer will support rapid switching from one user to another.

Each requirement could drive an independent solution approach. As Joel points out, each requirement, evaluated in isolation, may lead to a different solution. The problem is that we are finding local optima, and not looking at the problems introduced by the complexity of supporting all of these solutions.

Avoiding This Problem

How can we avoid this sort of problem in our own product development? A holistic view of the proposed solution is required to assess if there are too many features. Prioritization of those features will help us reduce the number to a reasonable level.

Incorporating elements of interaction design into our solution approach may be the best way to do this (short of abandoning a structured requirements approach).

ID and Structure

Each of the shutdown scenarios leads to a functional requirement. Each element of program design leads to one of the many ways to shut down or lock or restart the computer. Addressing the personal goals of each persona provides us with a cross-feature, holistic perspective. If our target audience includes Joel’s uncle, then we can make sure that our design approach accounts for the appropriate level of complexity and choice.

[Update]

Moishe Lettvin, one of the developers on the shutdown team for Vista, formerly at Microsoft, has written an article about the organizational and situational challenges faced by the team. He titled the article The Windows Shutdown Crapfest. That should give you a feel for how the now-Googler feels about the experience. There were 43 people involved, and they spent over a year. And the source code control system was frightening. Check out the comment thread on Moishe’s article too – it includes comments from other Microsoft and knowledgable anonymous people. Hat Tip to Scoble. Also, a followup from Moishe.
Summary

Multiple requirements can lead to multiple, locally-optimized solutions or features. A holistic view needs to be taken to assure that we aren’t introducing too much complexity with these variations of similar features. Interaction design gives us a big-picture perspective to make sure we aren’t making our software too hard for our target users to use.

Gifts for Geeks: Pre-Black Friday

Slightly off-topic

present

Many of us who are part of the Tyner Blain community are geeks, gadget hounds, and people who read books that make you think. All of us know someone like this. Tyner Blain is a mostly-for-free site – we just ask that you remember our name, join in on the discussion, and share the good stuff with others. Tonight we have a shameless, off-topic, self-promoting article.

Professional Shoppers

The professional shoppers out there know that Friday is known as Black Friday, one of the largest shopping days of the year – at least in the USA. New products hit the shelves in time for the holiday season, and retailers offer loss-leader sales to get shoppers in the door.

Tyner Blain is an Amazon.com affiliate – if you buy stuff we reccommend, we get a small commission. Not enough to pay for hosting the site, but enough to buy a copy of Karl Wiegers’ Software Requirements, 2nd Edition. We’ve put some great suggestions here, and feel free to use them – if you don’t want us to get an affiliate fee, don’t click on the links on this page, browse to Amazon directly and look up the product on your own.
Also, if you want to just use this post as a wish list of your own, send the link to someone else [my wife’s suggestion].

Amazon Gift Certificate

The perfect gift

What do you get for the person who already bought what they want? A gift certificate. Amazon sells gift certificate that can be used for anything from powdered lemonaide to DVDs to big screen tvs.

Wireless Joy

I love my Bluetooth gadgets, and can reccommend two in particular:

kensington

Kensington USB2.0 to Bluetooth adapter. My laptop doesn’t have bluetooth, but my cell phone does. With the bluetooth adapter, I can use my phone as a modem, when the hotel doesn’t have wireless (or we’re on the road). I can also transfer pictures and mp3s back and forth. The most practical feature – keeping a backup of my contacts on my laptop.

jabra

Jabra BT250V Bluetooth headset. Another especially handy toy – staying on the phone while I walk around with the phone in my pocket. I don’t know how many times I’ve ripped the phone out of my ear (or worse, out of my pocket) when the cord got caught on something. No more, with the bluetooth headset. I also get the twisted joy of walking around the airport looking like a babbling lunatic, as I talk into the empty space.

Tuning Out the World

Most of us have iPods or Zunes or other personal video/audio players. Most of us also have cheap headphones.

shure

The Shure E2c Sound Isolating Earphones are at the very top of my christmas list. I’ve been using Bose noise cancellation headphones for years – and based on the small form factor, and several reviews I’ve read, this will be my major upgrade for the year. Life savers on the plane, especially when I get stuck back by the engines, noise-reducing headphones allow me to listen with greater fidelity, without raising the volume to dangerous levels. Shure has higher performance versions than this model (and cheaper ones), but this is the sweet spot on the cost-benefit curve.

zune shuffle

The Zune is hot this year. Another great idea is the 2nd generation iPod shuffle (so tiny!).

Ever Get Thirsty?

wine opener

My friend Tom has the Metrokane Houdini-style opener. Coolest thing ever. If you’ve seen one and don’t have one yet, get it now. If you haven’t, ask a friend about it, then get one.

beer opener

Innocuous, yet indescribably cool in action, this bottle opener (beer and soft drinks) is equally cool to the Houdini opener, if your tastes, like mine, lead more to beer than wine.

Top-Shelf Books

For work-related books, take a browse of our bookshelf. If you want other really really good books, check out these three that are great both for learning new stuff, and thinking about stuff in new ways.

Amazon Gift Certificate

After all of that – you still may not know what to get – don’t forget The perfect gift.

Thanks

Thanks very much for either using one of these links, or at least tolerating their appearance here. Have a great Thanksgiving, or if you’re not in the USA, enjoy a day of two without us Americans pestering you.

Ten Requirements Gathering Techniques

Business Analysis, IIBA, Lists, Organizations, Requirements, Requirements gathering


The BABoK (Business Analyst Body of Knowledge) lists 10 techniques for gathering requirements. Here’s an overview of each one. For more details, check out the latest Guide to the BABoK.

  1. Brainstorming
  2. Document Analysis
  3. Focus Group
  4. Interface Analysis
  5. Interview
  6. Observation
  7. Prototyping
  8. Requirements Workshop
  9. Reverse Engineering
  10. Survey

1. Brainstorming

Brainstorming is used in requirements elicitation to get as many ideas as possible from a group of people. Generally used to identify possible solutions to problems, and clarify details of opportunities. Brainstorming casts a wide net, identifying many different possibilities. Prioritization of those possibilities is important to finding the needles in the haystack.

2. Document Analysis

Reviewing the documentation of an existing system can help when creating AS-IS process documents, as well as driving gap analysis for scoping of migration projects. In an ideal world, we would even be reviewing the requirements that drove creation of the existing system – a starting point for documenting current requirements. Nuggets of information are often buried in existing documents that help us ask questions as part of validating requirement completeness.

3. Focus Group

A focus group is a gathering of people who are representative of the users or customers of a product to get feedback. The feedback can be gathered about needs / opportunities / problems to identify requirements, or can be gathered to validate and refine already elicited requirements. This form of market research is distinct from brainstorming in that it is a managed process with specific participants. There is danger in “following the crowd”, and some people believe focus groups are at best ineffective. One risk is that we end up with the lowest common denominator features.

4. Interface Analysis

Interfaces for a software product can be human or machine. Integration with external systems and devices is just another interface. User centric design approaches are very effective at making sure that we create usable software. Interface analysis – reviewing the touch points with other external systems – is important to make sure we don’t overlook requirements that aren’t immediately visible to users.

5. Interview

Interviews of stakeholders and users are critical to creating the great software. Without understanding the goals and expectations of the users and stakeholders, we are very unlikely to satisfy them. We also have to recognize the perspective of each interviewee, so that we can properly weigh and address their inputs. Like a great reporter, listening is the skill that helps a great analyst to get more value from an interview than an average analyst.

6. Observation

The study of users in their natural habitats is what observation is about. By observing users, an analyst can identify a process flow, awkward steps, pain points and opportunities for improvement. Observation can be passive or active (asking questions while observing). Passive observation is better for getting feedback on a prototype (to refine requirements), where active observation is more effective at getting an understanding of an existing business process. Either approach can be used to uncover implicit requirements that otherwise might go overlooked.

7. Prototyping

Prototypes can be very effective at gathering feedback. Low fidelity prototypes can be used as an active listening tool. Often, when people can not articulate a particular need in the abstract, they can quickly assess if a design approach would address the need. Prototypes are most efficiently done with quick sketches of interfaces and storyboards. Prototypes are even being used as the “official requirements” in some situations.

8. Requirements Workshop

More commonly known as a joint application design (JAD) session, workshops can be very effective for gathering requirements. More structured than a brainstorming session, involved parties collaborate to document requirements. One way to capture the collaboration is with creation of domain-model artifacts (like static diagrams, activity diagrams). A workshop will be more effective with two analysts than with one, where a facilitator and a scribe work together.

9. Reverse Engineering

Is this a starting point or a last resort? When a migration project does not have access to sufficient documentation of the existing system, reverse engineering will identify what the system does. It will not identify what the system should do, and will not identify when the system does the wrong thing.

10. Survey

When collecting information from many people – too many to interview with budget and time constraints – a survey or questionnaire can be used. The survey can force users to select from choices, rate something (“Agree Strongly, Agree…”), or have open ended questions allowing free-form responses. Survey design is hard – questions can bias the respondents. Don’t assume that you can create a survey on your own, and get meaningful insight from the results. I would expect that a well designed survey would provide qualitative guidance for characterizing the market. It should not be used for prioritization of features or requirements.

Pairing Business Analysts

Business Analysis, Requirements, Writing

petronas towers

Pair programming is a bit of a foreign concept for many people in business. A few years ago, it was foreign to most programmers too. Pair programming is a powerful technique for software development because it allows two people to look at the same problem/solution from two different perspectives at the same time. Would that same approach work for business analysis?

Pair Programming

We haven’t written an introductory article on pair programming, and after reading what James Shore has written on pair-programming as part of his book, The Art of Agile Development, there’s really no room for improvement.

Pairing involves two programmers (or, less often, a programmer and a customer, tester, or other team member) working together to accomplish a single task. The person with the keyboard—the driver—focuses on the details of the task. He thinks tactically. The other person—the navigator—keeps the big picture in mind, ensuring that the task fits into the project as a whole, looking for ways to improve design, and keeping track of team guidelines. She thinks strategically.

James Shore

The interesting dynamic that makes this work is that the two programmers switch roles on a regular basis. As frequently as every half hour. Read this intro to get a better feel for it.
[Segue: Please read, review, and provide feedback for James on his book. It is awesome that he is doing the book this way, and you also get to read the early stages of a great book before most people.]

Strategic and Tactical Programming

Great programming is about both design and execution. The navigation and the driving, as James puts it. Having been a pair-programmer in a past life, I can attest to the power of this dynamic. When I think about really powerful solutions and innovations, they have come from (or at the least been improved by) collaboration.

Even without pair-programming, we can get the same benefits through feedback and reviews of our designs and our code.

How does this apply to business analysis?

Strategic and Tactical Documentation

When we create requirements documents, use cases, object oriented diagrams, and other artifacts, it is no different than programming. Instead of source code being written for a compiler to read, our documents are written for a person to read. We just don’t have the benefit of a compiler to point out our grammar mistakes, a code-styler to suggest more concise ways to write or more universal terms to use, or a set of automated tests to identify ambiguity and incorrectness. We have to get feedback the old-fashioned way, by reviewing our documents. The ease with which stakeholders read our documents is analogous to the performance benchmarks for code.

The organization of our documents is analogous to the design of a programmers code. The details we write are the embodiment of that design, just as code is the manifestation of the design. There are significant parallels.

We should be able to benefit from pairing when writing requirements documents.

The Biggest Improvements

When I think about the biggest improvements that I’ve seen in the documents we are creating on our team for my current project, almost all of them have come from collaboration. Formal and informal reviews of documents, brainstorming about how to represent a process, and discussions about the tradeoffs of documenting things in one way versus another.

This feels a lot like the code-reads we do as programmers. People who have pair programmed consistently admit that it is better than the do-review-redo cycle of traditional development processes. Would the same hold true for documenting requirements and processes? What about any writing at all?

Here’s another quote from James:

Pair programming produces code through conversation. As you drive or navigate, think out loud. Explain your assumptions, your short term goals, and any relevant history of the feature or project. If you’re confused about something, ask questions—the discussion may enlighten your partner as much as they do you.

Sounds a lot like the best parts of the documentation process to me.

What Do You Think?

Do you think it would work? Do you think you could sell it (justify the staffing of it)? Is there a downside?

Gathering Implicit Requirements

Interaction design, Product Management, Requirements, Requirements gathering, ROI, UX

magic hat

Johanna Rothman just wrote an article titled Implicit Requirements are Still Requirements. She points out that her expectations were not met, even though her needs might have been. Johanna also implicitly begs the question – how do we gather implicit requirements?
Johanna’s Experience

Johanna describes the process of installing updated drivers for an all-in-one scanner/fax/printer. The installation process did not live up to her expectations. It took too long, caused additional inconveniences for her, and when she was done, the user interface was inconsistent with her other applications. In short, her expectations, her implicit requirements, were not satisfied.

How Could This Happen?

When we prioritize the requirements for, and creation of a new product, we focus our effort on the most important elements. We may even exclude everything but the most important requirements. We spend time and money on those things that create the most value for our customers (or at least maximize our sales).

Even with a Kano Analysis driven prioritization approach, we start with must-be requirements, then surprise-and-delight, and eventually more-is-better requirements. We may never get to “implicit requirements.” Even if we have the time to get to them – we may not have identified them.

This could have been avoided, and we don’t need a magic wand to identify implicit requirements.

Interaction Design Will Help

An approach to software development that uses interaction design is much more likely to identify implicit requirements. Like user experience disciplines (UX), interaction design focuses on the users. The interaction design approach starts with identifying the typical users, represented as personas, and documents and prioritizes their personal goals. This user-centric approach would probably identify the personal goals that would guide software designers to prioritize a consistent interface and pain-free installation. This approach is a powerful way to design products that don’t suck.

We could also use an approach that melds interaction design with traditional requirements approaches.

Making Traditional Requirements Work

The biggest challenge in addressing implicit requirements is identifying them. Once we identify them, we can conciously prioritize them. Prioritization is a function of ROI, but ROI requires user adoption (or purchase). Bad user experiences create bad marketing, prevent repeat business, and prevent future sales. This is the mechanism by which we prioritie them, once we identify them.

Eliciting Implicit Requirements

One way to identify these requirements is through observation. By observing users of the product (or a competitor’s product), we can get a perspective on how users interact with the product. This is also known as ethnographic research. We may still miss requirements – the competitor’s product may not push on the pain points that would fail to live up to expectations. Or they may identify pain points in the competitive product that present opportunities for us.

We can combine this observation with the use of prototypes. Prototypes can be used to document requirements, and they can even be used as the first iteration of an incremental delivery. More importantly, they can be used as a tool for gathering requirements.

Prototypes Uncover Overlooked Implicit Requirements

Prototypes simulate the product. Interacting with the prototype simulates interactions with the product. If we’ve done something wrong, or are about to do something wrong, a prototype will help us uncover it. We need to get feedback from the users (or people who match our target personas) about how the prototype meets and fails to meet their expectations. Other requirements gathering techniques can help us define the explicit requirements, and then interacting with the prototype will help us identify the implicit requirements.

Conclusion

Implicit requirements are real. And we have ways to uncover them. We can use interaction design as our approach. Or we can use traditional requirements techniques, and elicit the implicit requirements through prototyping and observation.