How to Deal with "Bonus" Features

Here’s the situation: You’ve created the best requirements document ever written. You are eagerly reviewing the output from the development team (High Level Design Documents if you are lucky, early releases otherwise). And then it happens… you find out that there are “features” coming from the development team that weren’t included in the requirements. This situation—developers adding features to the system that are not specified in the requirements—is known as gold plating.

What do you do?

Ideally, you stop the gold plating. Gold plating frequently indicates one or more organizational problems, such as:

• The organization does not understand that gold plating is a problem and that there is a high cost for this unnecessary development in the form of additional testing, documentation, and maintenance.
• The development process is not well-defined and the organization has not established a process for development which adheres to the requirements.
• The development process is well-defined, but management has either failed to communicate it or failed to enforce it.

If there is an organizational problem, it will typically take some time to fix. Unfortunately, while product managers can be the catalyst for organizational change, we typically do not have the authority to impose change. If you can’t immediately stop the gold plating, how do you address this situation?

Features have been added to the system, so the entire team needs to know about them in order to properly address them: the documentation team will need to write about them, the quality assurance team will need to test them, etc. The information about these features should be added to the documents used within your organization to understand the capabilities of the system. If you have design documents, it will fit nicely there.

When the requirements documents are the primary documents used to understand the capabilities of the system, my line of reasoning says the information belongs there. However, these new features are really not requirements because the business unit has not asked for them. What’s a product manager to do?

I was recently faced with this situation. After soliciting advice from my colleagues, I decided the best approach would be to add the information about these features to an appendix in the Software Requirements Specification. It worked well as features were documented in an obvious location, yet not presented as requirements.

And, for those of you who are wondering, yes, the entire team is working on process improvement as well.

Karl Wiegers - More About Software Requirements

Karl Wiegers is one of the favorite authors around the Seilevel office with his Software Requirements, Second Edition considered one of the better books on the topic. Karl’s latest, More About Software Requirements – Thorny Issues and Practical Advice, arrived in January but unfortunately has managed to sit in my briefcase ever since awaiting a little free bandwidth. I ended up with a nice chunk of time on a trip recently and the book proved to be the perfect airplane read – lots of great information in a well-written, concise, easily digestible format. Some of Karl’s content is going to be the basis of my next couple of blog posts, but I thought I would take this first post to introduce the book to everyone and provide an overview.

The book’s structure presents 100+ “lessons” grouped into seven categories. Following are some of the highlights I took away from each category.

Essential Requirements Concepts

• A helpful primer on requirements concepts and terminology
• “10 Cosmic Truths About Software Requirements”

The Management View of Requirements

• Real-world examples focused on the value of better requirements engineering
• An excellent discussion around the importance of measuring requirements activities
• Overview of using requirements as the basis of project estimation

Customer Interactions

• “The Myth of the Onsite Customer”
• A better way of asking “why”

Use Cases

• A breakdown of use cases versus scenarios versus stories
• Clear delineation between use cases and functional requirements

Writing Requirements

• Actionable tips for better requirements
• “The Fuzzy Line Between Requirements and Design”

The Requirements Process

• How and when to baseline
• How requirements are like an elephant
• How to overcome the limitations of natural language by using requirements models

Managing Requirements

• How to handle requirements across multiple releases
• Breakdown of business rules versus requirements
• The case for and against requirements management tools

Understand that the book weighs in at less than 200 pages and therefore does not go into great depth on any of the subjects it covers. That said, it does a fantastic job of hitting the high points across a wide range of topics. I think this is a fantastic read for anyone that wants an introduction to a wide spectrum of requirements issues and techniques. If you are trying to evangelize an improved requirements process in your company this might be a good book to leave on your manager’s desk as a means to start the conversation. For those folks that have been in the requirements trenches a while longer, there is still good value in the book. It may not blow you away with any major new concepts or insights, but it will present a number of useful tips and techniques and perhaps get you to look at some well-covered topics with a fresh perspective.

As noted, I am going to drill down further into a couple sections of the book over the coming weeks, but hopefully this overview has whet your appetite for “More About Software Requirements.”

JAD Sessions Part 2 - Roles

JAD Sessions have clearly defined participant roles. Each person has a critical part to play to make the session successful. Because of the short timeline (3-5 days) participants must be absolutely clear on how the JAD session will work and what their roles and responsibilities are. We recommend creating a training session tailored to your group detailing hour by hour what will be covered in the session and going over the rules. Below are the standard JAD session roles and responsibilities.

Executive Sponsor: The executive sponsor has the ultimate authority to make decisions about the project. The executive sponsor provides credibility to the process and ensures that all participants understand the importance of the process. They should attend the opening and closing of the JAD sessions to communicate the importance of the project.

Project Lead/Manager: The project manager provides information about the project regarding scope, time, coordination issues and resources.

User: Users are a majority of the group. They represent business areas that are directly or indirectly being affected by this project. They are experts in their area and can make decisions about their work. They are the primary source of the input to the requirements and during the JAD sessions.

IT Representative: IT representatives provide technical information when it is required, help develop architectural models and specifications, and determine what is feasible.

Facilitator: Prepares a draft of the requirements and organizes the JAD sessions. During each session, the facilitator controls the meeting and keeps the group on the agenda. The facilitator is responsible for classifying issues into those that can be solved as part of the meeting and those which need to be assigned for follow-up. The facilitator does not contribute content to the meeting and simply drives the conversation. Following the JAD sessions, the facilitator will create the final version of the requirements documentation.

Scribe: The scribe participates in JAD sessions by capturing the discussion and ensuring that there is clarity around decisions. Following the JAD sessions, the scribe will create the final version of the requirements documentation.

These roles and responsibilities come from Joint Application Development by Jane Wood and Denise Silver.

Why Finding a Job Can Be Puzzling

Who’s up for another brainteaser? Well you need to be because it doesn’t look like they’re going away anytime soon. Try this one-

Why do software companies subject job candidates to brainteasers and puzzles?

Most candidates are already at least a little nervous about the interview to begin with and brainteasers can certainly add to the stress. I have not come across any studies that give scientific support to the idea that success at brainteasers and logic puzzles predicts success at the job. So why use them?

Recruiters and interviewers use these brainteasers for one thing: to begin an innocuous conversation that will expose a candidate’s intelligence and/or ability. Go ahead and blame it on Microsoft. Ever since Microsoft made headlines for its unconventional approach to interviewing, more and more software companies are using their approach. Why? One answer is that it has proven to be a key tool for employers to use now that it has become more difficult to give intelligence tests to candidates. For now, at least, puzzles are seen as a decent alternative. By giving candidates a good puzzle to solve you get one data point about how clever they are while the associated dialogue provides some valuable problem-solving interaction with the candidate as well.

Recruiters are constantly faced with hundreds of resumes from what look to be qualified candidates for every single position. How is one to know who to select, especially when the focus is more on what candidates may perhaps do in the future rather than just what they have done in the past? In today’s ever-evolving software world, what is really needed are inquisitive, perceptive, intelligent candidates who welcome challenges, exhibit mental deftness under demanding conditions, learn rapidly, defend their ideas, and display enthusiasm for what seem to be impossible tasks.

There are two aspects to using brainteasers effectively that I think are important to keep in mind. The first is that any puzzle should be carefully constructed to be more of a logical/analytical exercise rather than something that is purely dependent on the candidate discovering some sort of “trick.” Unless you are looking for the 1 candidate in a hundred that will get “the trick,” make sure your exercise is structured so the 10 candidates in a hundred that you actually want to find are able to realistically solve it. The second aspect to consider is that recruiters should be less focused on making sure a candidate comes up with the “right” answer, and much more concerned with how they get there. Do they give up on the first try? Do they come up with plenty of scenarios with which to solve the puzzle, but have trouble applying those solutions? Do they present their ideas in an effective and professional manner?

The use of brainteasers or other problem-solving exercises in the interview process helps to narrow down the considerable number of “maybes” that flood a recruiter’s inbox. They are used to recognize candidates who are not only book-smart, but who can get things done when faced with new challenges in high-pressure situations. In my world of software consulting, it is imperative to possess the ability to confidently and skillfully present new ideas and face difficult challenges at the drop of a hat. A well crafted brainteaser can help gauge a candidate’s ability in this regard.

Levels of Abstraction in Use Cases

I explored the differences between writing use cases as generic scenarios versus specific scenarios the other day on the Requirements Defined Message Board.

I've most commonly seen and written use cases in the generic form. However, an alternative is to write them as more specific instances of those scenarios. The specific instance version is something I would use in test scripts, more than in use cases. Or at most, I would use it to provide additional information in story form, but not as a replacement for generic use cases.

The actual difference between these two is really in what nouns are used. For example, in the generic scenario, the actor would describe a user role, but if you wrote them as specific instances, the actor might be a specific person representing that role. Or, the direct object of the sentence might be an abstract object in the generic scenario, but a named object in the specific scenario.

To illustrate the difference:
Let's say you have a system like Amazon.com. You need to write a use case to capture the purchasing process for a book. You define your actor for the use case to be an online customer.

In your generic scenario use case, you might have a step that looks like:
"Online customer searches for book."

The comparable step in a specific instance of this use case would be:
"John searches for 'The Not So Big House'."

Of course, you could also get too general:
“Actor searches for object.”

Now, I can see that the specific scenarios may be easier to understand. Word choices like buying an “object” are hard to visualize, so a business user is likely to have their eyes gloss over if they cannot relate to the interaction described.

And certainly, the specific scenarios are more interesting to read. However, requirements are not meant to be interesting reading. Variety is significantly less important than clarity when documenting the system’s required functionality.

Therefore, as a general rule, I prefer the generic version of use cases.

When I read the more specific example, I have to think about who John is and what it would look like if we used Jane or Joe. There is a level of abstraction I end up doing in my head to remap John to being just any online customer. The same thing happens when I read the book title. I have to wonder whether the use case represents searching for a book or any type of object I might buy on Amazon. Even worse, if I do not know the title is actually a book, I'm going to be completely lost.

Imagine reading more than just one line, but rather an entire scenario in the specific instance format. It is that much more confusing to understand. After reading this much detail, I find that I lose touch with the original goal of the scenario.

A final concern is that you will miss the alternate scenarios in the use case. Typically, these fall out naturally if you review each step of a use case and look for alternates. But if the use case steps require more mental processing to understand, identifying alternates on top of that is even more unlikely.

I do think the specific scenarios have a place in the requirements documentation. If you write a generic use case and provide what I call a “story” along with it, then that can be extremely helpful to the visualization process for the reader. But the generic scenario is far clearer for the team to work from as the actual use case.

The key take away here is that there are varying levels of abstraction here. The abstraction hierarchy looks like object -> book -> Not So Big House. Each level down in the abstraction hierarchy is more specific. You can write the use case as a customer searching for an "object", or more specifically, searching for a "book", or even more specifically than that – searching for "The Not So Big House" book. At the top of this hierarchy, you have to be careful that you are not so abstract that your use case is not understandable.

The important thing is to know which level of abstraction is the right level. I think you need to pick "object" when all object buying is the same. But you need to pick "book" when buying a book is different than buying a CD, DVD, printer, shoes, camera or a purse. And I don't think you ever should use a book title, except in writing stories to enhance use case understanding.

JAD Sessions Part 1 - The Need

A few years ago Joint Application Design (JAD) was all the rage, however lately I have heard nary a peep from the JAD front until recently. As a result of a couple of customer requests for JAD, I thought it would be appropriate to discuss JAD. Like most processes JAD is neither inherently good nor bad, it is simply another tool that you can use in your quest to create great requirements.

In "Joint Application Development" by Jane Wood and Denise Silver, the authors very succinctly describe what they believe is a problem with “Traditional Design”.

In most organizations, the systems development life cycle begins with the identification of a need, assignment of a project leader and team, and often the selection of a catchy acronym for the project.

The leader pursues a series of separate meetings with the people who will use the system or be affected by it.The leader continues these meetings over time. Often the key people involved are not so easy to reach. But eventually, having documented everything possible, the leader translates copious notes into a personal terminology. That’s when it becomes apparent that the requirements from, say Accounting, don’t mesh with what the Sales department wants. So the leader calls Sales and finds out the contact there is in the field and will not be back until tomorrow. Next day the leader reaches Sales, gets the information, calls Accounting, and of course the person in Accounting is now out of the office, and so on.

When everyone is finally in agreement, alas, the leader discovers that even more people should have been consulted because their needs require something entirely different. In the end, everyone is reluctant to "sign off" on the specifications.Other times, signing off comes easily. But when the system is delivered, it often has little to do with what the users really need.

So what is JAD? JAD was conceived in 1977 by Chuck Morris and Tony Crawford of IBM and centers around a single 3-5 day workshop session where all stakeholders are in a room and can hash out issues and problems without communications delay. JAD consists of 5 phases:

Project Definition – Meetings with the management stakeholders occur (those who requested the system). Out of these meetings, the basic requirements of the project are defined, open issues are identified, and assumptions (business rules) are listed. In addition, the project session is scheduled and the meeting participants are invited. A document is created which will be the foundation for the final document.

Research – Meetings occur with the actual users of the system. Business processes are mapped, design elements are gathered, screen shots are created, and design issues are considered the same way they would be with traditional design. Based on this research, the agenda is created for the session.

Preparation – Visual aids and other materials for the session are gathered and a working document which contains the proposed requirements is created which will be the foundation for discussion in the session.

The Session – This is the foundation of what makes JAD a distinct process. It is a 3-5 day workshop that will use the working document as a guide to define business processes, data models and perhaps even mockups. Agreed upon decisions are documented for the final document.

The Final Document – The information gathered in the session is used to produce the final document which is then sent to the JAD participants for final review in one or more review sessions.

Although there is heavy emphasis placed on the session itself, I would argue that the project definition, research, and preparation are actually the key to the JAD session success. Without good planning, the JAD session simply will not be productive.

Stay tuned for Part 2 where I discuss the roles in the session itself and Part 3 where I discuss JAD war stories.

The Product Manager's Role in Software Usability

There was another fantastic post a few weeks back from Scott Selhorst over at Tyner Blain. This entry from his foundation series had Scott covering the topic of user experience disciplines. Software UI design is an area that has been near and dear to my heart ever since I majored in human factors engineering as an undergrad. From then on, regardless of my official role on a software team I have always tried to apply what few UED skills remain in my toolbox to try to deliver software where the users have been a prime consideration.

Scott's post was followed by a reply on Roger Cauvin's blog and an unrelated entry from Joel Spolsky. All of these got me thinking about the contribution that a Product Manager should make as it relates to software usability. I see there being three UED aspects to our role.

First, the Product Manager must help the rest of the team understand how the user expects the system to behave. This key contribution to effective user interface design is a fantastic insight that Joel Spolsky boils down to a single sentence-

Something is usable if it behaves exactly as expected.

Seems almost laughably simple, but I think it is a non-obvious concept that all Product Managers should work to internalize. I don't know if we need to follow Joel's advice and tattoo it backwards on our foreheads, but it would probably make a great quote to stick on a post-it on your computer monitor whenever you are doing work that will directly impact the user experience.

Next, effective Product Managers must help their teams measure whether or not they are meeting the users' expectations. This is the point made by Roger in his reply to the Tyner Blain post.

Your product manager's role is not to be an information architect, graphic designer, or usability expert. However, she should specify, in measurable terms, how usable the product should be. The usability requirements are the metrics by which we judge whether the designers have done a good job.

Although we have to realize that sometimes user expectations will be purely subjective and impossible to quantify, product managers must do their best to create measurable criteria by which usability requirements can be evaluated.

Finally, the Product Manager must be a key advocate for usability and the overall user experience. What exactly this aspect of the role entails will be different from company to company.

In some small startups, the Product Manager may need to be the person to step up and lobby for the hiring of information architects and graphic designers. If those resources can't be acquired for some reason I agree with Roger that Product Managers should not try to take the place of the experts, but we must instead do whatever we can to at least bring those voices into the process by any means possible. Even if is nothing more than applying a little knowledge picked up from reading The Inmates Are Running the Asylum, injecting some small amount of user-focused design into the engineering process is something that a Product Manager must be willing and able to do when needed.

In larger companies with dedicated UED resources the Product Manager will be able to focus more on being the canary in the coal mine. Do the up front work to understand the users' expectations and create measurable requirements for the design team, but then be ever vigilant and prepared to raise the alarm if usability starts to fall ever so slightly out of the software development equation.