What Color Is Your Unicorn?

[SPOILER WARNING - Seilevel asks that any Lisa Frank fans please not read this article]

A: Unicorns don't exist.

This is a commonly known fact in most circles, but not in the requirements game. There is a strong tendency for a lot of people to spend a lot of time discussing intricate details of systems that don't, can't, and will never exist. I have seen weeks of heated arguements over what color the unicorn should be only to have the belated realization that it never mattered in the first place. Time and resources are wasted, slowing the project and frustrating participants. At the end, either the work is abandoned because it's not in scope, or, worse yet, a developer is driven insane developing a unicorn management and coloration system only then to discover that a key component of the system doesn't really exist.

Why Unicorns?

Why does this happen? Because "unicorns" are interesting and fun to talk about, they also do "magic" things, like cover for missing information. Does that make unicorns exist? No. I find that when "unicorns" start popping up in requirement conversation, it's indicative of:

1. A premature jump to design and implementation


2. Dodging a hard or open question relating to requirements


3. Unclear understanding of system inputs and dependencies


4. Unclear business objectives


5. Implementation bias towards "hot new technology" or pet solution

Managing Your Unicorns

You don't need a golden bridle to rein in the fantastical, just some presence of mind and a few directed questions to gently reset the conversation back to reality. Here are some suggestions.

1. Is an ungulate monoceros currently in scope?


2. Unicorn? Interesting... What is it the unicorn does that pleases you? (Use the description of the unicorn to glean the underlying requirements)


3. What is the business objective that the unicorn will help acheive? Is the unicorn the only way to do so? Why? (Again, use the description to glean the underlying requirements)


4. What are the inputs and outputs of this system? Do they currently exist? (Be especially gentle with this one-- people can get a little upset when they have to face reality that maybe unicorns won't be able to solve the problem.

Requirements Limericks

I'm not sure how this came up, but when you get a collection of requirements experts in a room for social occasions, odd things happen.

Sometimes, those odd things take the form of limericks (only because we decided that we'd already done Requirements Haikus to death).

Among the entries:

There once was a user named Mary

Who thought the requirements process was quite hairy
Then she worked with Seilevel who was so much fun
They provided grins and laughs by the ton
Now she’d rather help with requirement than watch Tom and Jerry

There was a BA from Austin

Who hopped on a plane to Boston

She opened her suit case

She cranked out a use case

And found a long doc to get lost in

There was a BA from Texas

Who drove a purple Lexus

He was a consultant

His clients exultant

In meetings he was clearly the nexus

The Trace Race

In the early days of the Internet, my then-CEO had no problems selling a complete copy of our proprietary database in lieu of the normal subscription fee. When I asked him why he was willing to do so, he smiled and said "It will be worthless in a year. There's no way they can maintain it." The core competency of the company, I realized, wasn't the information itself, but rather the way it was managed.

The same applies for requirements.

Believe it or not, gathering accurate requirements is only a small part of the requirements process, and arguably not even the most important part. Rather, I believe how we manage those requirements is the core competency of a truly revolutionary product development experience. The catalyst for revolutionary requirements management is very easy to describe but hard to do: Traceability.

Traceability is a simple enough concept: requirements have associations to business objectives, related requirements, and interdependencies. Without traceability, a single requirement change can render otherwise accurate requirements unusable, especially if there are many dependencies to that requirement.

Traceability is important because it enables:

• Project Success Metrics


• Automation of Project Change


• Change Impact Measurement


• Testability

All of which are keystones to presenting information required to make smart decisions, tools to automate requirement changes, and maintaining focus on the business objectives (aka "Now why are we doing this, again?").

Sounds easy enough, right? Unfortunately, if traceability is not part of the plan from the beginning, it can be almost impossible to implement after the fact. Indeed, many requirement documentation efforts start with excellent requirements only to fall apart in short order when the first major revisions are made (and even more so if the original business objectives fade from memory).

This is why requirement management tools can be so powerful, by enforcing traceability from the start, and providing an easier, automated method to add in the missing parts. Think about how you will modify and manage your requirements the next time you decide on getting a "head start" in lieu of establishing clear, measurable business objectives.

The Personal Trainer Has Much Knowledge

Posted by Special Guest Contributor - Ginger Nedblake

A few months ago, I started a strength training class with a trainer, Mandy. Twice a week I submit myself to her will in the hopes of achieving my fitness goals. And from my very first meeting with her, I realized that my job of requirements analyst and her job of banishing flab have many similarities and that she has some skills I can use in my job.

Here is what I have learned from her:

Keep the Goals in Mind

At our initial meeting, Mandy asked me to fill out a list of goals – the why of what I was doing. Being a responsible requirements analyst, I knew my goal couldn’t be to “get in shape.” My goal, or high-level functional requirement, had to be measurable.

There ended up being six goals for my fresh attempt at fitness. I printed copies of my goals and look at them whenever I don't feel motivated, such as when I am about to choose working late or going to dinner with a friend over going to Mandy’s class.

I have seen too many projects where we come up with our high-level scope requirements for a project and then dutifully archive them and never look at them again. It would be much more useful to review those goals before every project review or discussion. In addition to helping with focusing attention or determining if a project change is scope creep, reviewing the goals can remind us of why we are doing the hard work.

(And with a nod to the project managers out there, when looking at my goals doesn’t motivate me to go to class, I look at how much money I would be wasting if I didn’t go – the per class price. And then I go.)

Be Tough and Be Kind

I simultaneously adore and loathe Mandy. I loathe her for all the obvious reasons. She is cute and blonde and she makes me do 50 standing lunges with 12-pound dumbbells. That is to say, she is evil.

But the reasons I adore her are much more numerous, and I have learned a lot from her when it comes to interpersonal communication as motivation.

1. “ Yes, I need you to do that.” When someone asks “Do I have to…?”, Mandy says yes. She always says yes. If it is written on our exercise sheet for the day, we have to do it. She knows the reason the exercise is there. Many requirements analysts would benefit from the same quiet confidence. If a requirement has been elicited, written, reviewed, and approved, it needs to be done even if it is hard, even if the technical team has sore muscles or didn’t get enough sleep, or even if it pushes the system limitations.


2. “You can use bigger weights.” When Mandy sees that someone isn’t pushing hard enough, she makes her switch weights. She wants us to get the most out of our repetitions, and quickly determines when we can do more. Many requirements projects would benefit from that same time-benefit analysis. Reviewing the requirements and goals of a project to ensure that when we touch the code, we are making the most strategic, beneficial changes and that we are pushing ourselves.


3. “Good work.” Mandy always compliments us on the work we have achieved. She notices the small improvements as well as the big changes. The small kudos are very motivating to me. Acknowledgement that what I have done is tough, even if it is a small task, pushes me to do more. Technical teams and customers are motivated by the same feedback. Even the most hardened software engineer appreciates positive feedback. Whenever a developer has shown me something he or she has done, I always find something positive to say, even if they are just doing what the requirements told them to do:


• “Thanks for showing me that. This is really going to make the customer love it.”
• “I know adding that field was tough, but it looks great.”
• “It is so cool to see that requirement come to life. Thank you!”

It seems cheesy, but I honestly think those daily affirmations make for a better relationship with the technical team. And, I have seen evidence for this hypothesis with my experience with Mandy. Even as I roll my eyes, I appreciate her recognizing the effort.

Remember the Safety Requirements…First!

When helping teams with their requirements process, I often am asked to explain the goal or use of a hazard analysis. Requirements analysts do not always understand the purpose of declaring the safety requirements up front and tagging or storing them in such a way that they easily can be identified as the safety requirements. This is seen as just another administrative task.

The software we develop is tightly regulated; we are required to identify our safety requirements, but in addition to meeting the regulatory standards, the practice helps to draw attention to your critical requirements, ensuring that you don not design or code software that could cause injury, death, or financial loss to the client. And these safety requirements need to be defined early in a project and reviewed often.

Mandy never forgets the safety requirements. In a room full of ten women doing ten different exercises, she can quickly point and say, “Cindy! On this one you are going to want to use lighter weights so you don’t hurt your elbow." She seems to have some sort of sixth sense about preventing injury, and she keeps in her mind the past or potential injuries of all the women in all of her classes. It is quite something to behold. I would love to see requirements analysts storing all of the safety requirements for a project or product in their mind and recalling them immediately to ensure that there is no harm.

The Actor Factor

Certain methodologies suggest that you identify system Actors early on in the process of defining your problem and solution.

I think this is a great idea, and this is why.

Identifying the Actors early on in you process helps define the boundaries of the business context. By knowing the ‘Who’ you have in effect defined “Who Isn’t.”

You have also effectively identified your SMEs for your business and system requirements. They are going to be people who fall into one or more of the real-world roles (or manager’s for those roles) represented by the Actors you have defined.

For each Actor, you can define the actions they will perform in the system and you have identified the candidate set of use cases to be detailed as part of you requirements effort.

And don’t forget, Actors can be other systems that will interact with your system, so you have also begun to identify the functional/data integration points that will feed certain non-functional requirements.

Ask, Don't Tell

As you may have surmised from other posts, I'm a daddy. I have an almost-two-year-old little boy who, as his age would suggest, is in the midst of the "terrible twos" (by the way, most people I've talked to about the phenomenon agree that it starts around 18 months and lasts until college). He's extremely strong-willed, and he is also extremely vocal. So, when he doesn't want to leave the kitchen even though you're trying to cook, or empty the dishwasher, or clean up, or unload the groceries, he's very clear about it!

I used to try to instruct him to come out of the kitchen, or come with Daddy, or play with puzzles, in order to get him to do what I want (leave the kitchen), and he simply replies, "NO! NO! NO!" Eventually, I found a surprisingly powerful way to deal with his less-than-helpful single-mindedness, though -- asking questions. If, instead of suggesting an approach, I ask him if he would prefer to read a book or flop on the bed, he usually picks one of the two choices and quickly runs out of the kitchen. If, instead, I had suggested that we do one or the other (or both), it would have been NO-time again. When it's his choice, though, he's happy to oblige.

I've found the same approach to be equally powerful with my requirements work. If I come into a requirements gathering situation and begin telling people how things are going to go/work, I find that I often encounter resistance (stated or unstated). However, if I plan ahead and have several options available in my toolbelt, then I have the ability to ask SMEs how they'd like to work together. They get to be in charge of the decision, even though I've only offered them viable choices to pick from. I realize that this may be a bit deceptive, but I think of it instead as me helping my SMEs make good choices, often in spite of any preconceived notions about requirements work.

It's important to note that, both with my son and with my SMEs, I limit the choices. I don't ask my little boy "What would you like to do?," but instead "Would you like to do X or Y?" Similarly, I don't ask SMEs how they would like to provide their requirements, I ask them "Would it be better to sketch out the existing process on the whiteboard or for me to watch you work through it at your desk?" I don't offer alternatives that I don't think would work (like "playing with knives" for my two-year-old or like "please fill out this use case template for me" with my SMEs), just those I think are solid options for the situation.

It's hard to follow this approach all the time, especially when I'm in a frustrating situation or environment, but when I'm able to take a step back and put the other person in the driver's seat (but only of a car that I think is appropriate), we both win.

Three simple but powerful techniques for modeling Data

We often spend the majority of our modeling time on use cases, process flow diagrams, and other tools that model behavior. These behavior models are great tools for driving out functional requirements but they don’t explicitly address all of the data objects, attributes, and relationships associated with the behavior. For that we need a set of data models and modeling techniques. In fact, it is hard to imagine a software requirements effort that does not include some data modeling effort. Switching your point of view from behavior to data and back is a great way to identify questions you should be asking about when and how data objects are created or used in the process. The answers to those questions will raise more questions about the process and will ultimately result in a much more complete set of requirements.

Here are three simple but powerful techniques for modeling Data:

First, start with any narrative description of the business process such as a write up of your notes from meeting with project sponsors and subject matter experts. Scan through the text and identify all of the nouns. The resulting list of nouns includes candidate actors and candidate business objects. At this stage we are looking for business objects that are real things in the real world, not things in the software. Like I said, simple but powerful.

Second, construct a business object model for each use case you write. This step is often overlooked because we know we will need a consolidated object model covering all of the use cases so modelers tend to start with the overall model and just update that model with new information as use cases are developed and analyzed. Developing an object model specifically for a use case is a great way to make sure we focus on the data requirements for that use case. We still need the consolidated model but the use case specific models are another simple but powerful technique.

Third, work through the object model, one object at a time, and ask about the things users can know or remember about the object. These are the attributes of the object, including attributes that define an object’s relationships to other objects. For example, for an order we can remember the order number, order date, items on the order, etc. Among other things, this tells us the order can have a relationship with many items. But, how many items? Can an order have zero items? Is there a maximum? Work through this step carefully as there can be a lot of attributes and relationships.

There are many other data modeling techniques but these three are easy to use and will really pay off by helping identify requirements you might otherwise miss.

The BA as SME

Much of the training that we give business analysts relates to requirements elicitation from Subject Matter Experts. We help business analysts to make the appropriate preparations for interviews, and teach them how to ask the right questions to get to "the heart of the matter" without being experts themselves.

However, on large projects of long duration, an interesting phenomenon starts to take place. The BA's become the Subject Matter Experts. It's not necessarily an in depth expertise about particular areas of the system - that would frequently be just a duplication of knowledge from a particular SME. What we see quite frequently, however, is that the BA's are the people who know the most about the system as a whole. True SME's are frequently siloed into particular areas of a system. For example, we've worked on credit management systems where the people who knew contracts knew nothing about originations or accounts receivable, while the people who managed originations knew nothing about products that weren't in their systems. As BA's, we became the SME's for system interactions. When "silo" SME's wanted to know how portions of their business interacted with others, they'd go to the BA's first.

This is both a good and dangerous place for BA's to be. It's good in that we have enough of a holistic view of the system that we should be able to write better requirements. It's dangerous in that we need to be VERY careful that we don't start making bad assumptions based on our system expertise. The mitigation for this is to stay VERY closely focused on the measurable business objectives for the project and the project success metrics.

Project Vision Workshop

1. Identify the Problem
(Common techniques used to find the problems behind the problem are brainstorming, fishbone diagrams and Pareto diagrams.)

1. Ask the group: What are the problems (aka business opportunities)?
2. Write down each problem and see if everyone agrees.
3. Then ask the group again: What is the problem, really?
4. Continue to ask "why?" to find out what the problem "really" is.

2. Formulate Problem Statements
1. For each problem you have identified, complete the following:

The problem of [describe the problem]

affects [the stakeholders affected by the problem].

The impact of which is [what is the impact of the problem].

A successful solution would [list some key benefits of a successful solution].

3. Identify the Stakeholders and Users
Requirements have many sources. They may come from anyone with an interest in the outcome of the project. Customers, partners, end users and domain experts are some sources of requirements. Management, project team members, business policies and regulatory agencies can be others.

1. Interview decision-makers, potential users and other interested parties. The following questions are helpful:
a. Who are the users of the system?
b. Who is the economic buyer for the system?
c. Who else will be affected by the outputs that the system produces?
d. Who will evaluate and bless the system when it is delivered and deployed?
e. Are there any other internal or external users of the system whose needs must be addressed?
f. Who will maintain the new system?
g. Is there anyone else?
h. Okay, is there anyone else?

2. Document initial profiles of potential (or actual) users of the system and their environment in the Vision document. (These will map to the roles of the human actors of the system being developed.)

4. Define System Boundaries
(The system boundary defines the border between the solution and the real world that surrounds the solution.)

1. Name the system actors and define each actor’s role.
2. Define the information—in the form of inputs and outputs—that is passed back and forth from the system to the users that live outside of the system.
3. Define the interfaces between the system and the external world.

5. Define Features of the System
1. Create a list of features you want in the system based on the benefits listed in your problem statements.
2. Describe each feature briefly.
3. Assign each feature a priority (Clarify the scale that priority is based on. Release version? Resource availability?)

6. Identify System Constraints
(The information gathered here will be the initial input to the design constraints defined in the Supplemental Specifications.)

There are a variety of sources of constraints to be considered. Much of this information may be documented in the business rules. Following is a list of potential sources and questions to ask:
1. Political: Are there internal or external political issues that affect potential solutions? Interdepartmental?
2. Economic: Which financial or budgetary constraints are applicable? Are there costs of goods sold, or product pricing considerations? Are there any licensing issues?
3. Environmental: Are there environmental or regulatory constraints? Legal? Other standards we are restricted by?
4. Technical: Are we restricted in our choice of technologies? Are we constrained to work within existing platforms or technologies? Are we prohibited from any new technologies?
5. Feasibility: Is the schedule defined? Are we restricted to existing resources? Can we use outside labor? Can we expand resources? Temporary? Permanent?
6. System: Is the solution to be built on our existing systems? Must we maintain compatibility with existing solutions? Which operating systems and environments must be supported?

7. Review the Effort
1. Ask the group:
a. Have we fully explored what the "problem behind the problem" is?
b. Is the problem statement correctly formulated?
c. Is the list of stakeholders complete and correct?
d. Does everyone agree on the definition of the system boundaries?
e. If system boundaries have been expressed using actors, have all actors been defined and correctly described?
f. Have we sufficiently explored constraints to be put on the system?
g. Have we covered all kinds of constraints - for example political, economic and environmental?
h. Have all key features of the system been identified and defined?
i. Will the features solve the problems that have been identified?
j. Are the features consistent with the constraints that have been identified?

2. Review any issues generated from this discussion and assign any action items for issue resolution.

Techniques for eliciting requirements include interviews, brainstorming, conceptual prototyping, questionnaires, and competitive analysis. The result of requirements elicitation is a list of requests or needs that are described textually and graphically, and that have been given priority relative to one another.