Your first responsibility in good requirements management is requirements elicitation and we’re going to give you the 411 on how it works. Requirements elicitation is the method for determining the needs of all the customers and users in the project. This is a very important process, and it requires a collaborative effort between the development team and the client. Our new program helps to facilitate requirements elicitation, making it a straightforward process that allows you to easily organize and prioritize important information.
One thing to keep in mind about requirements elicitation is that it isn’t necessarily just a matter of asking the customer what they want. You have to dig deeper than that, read between the lines, and learn to use your own expertise to understand what they truly need. It’s sort of like when you take your broken-down car to a mechanic. He doesn’t ask if you want him to replace this part or tighten that screw. All he has to know is that you need the car to run – he’ll figure out the rest. So, when you’re meeting with a client, don’t just ask “What do you want?” Instead, ask “What do you need to do?” That way, your client will tell you what they ultimately need to accomplish, and you can help them find the best way to make that happen.
“Why?” is another important question to have in your arsenal. As the customer presents his requirements, don’t be afraid to ask “Why?” when appropriate. Chances are it will help lead the development team and the client to a better understanding of both the problem and the solution.
Take care to learn as much as you can about the client’s current processes. What don’t they like about it now? What do they want to see improve? And don’t just write down what they say and leave it at that. Create a conversation with your client, with lots of give and take. Suggest ideas that come to you on the fly and get their feedback on those ideas.
You should review the full client vision, including future goals and tangential projects, and interview the client stakeholders to get the full set of requirements.
There are often very important unstated requirements that are uncovered and are essential for the project to meet its objectives. As a result the project will meet the written requirements but will not be a success, as the client will be dissatisfied because it doesn’t fit the full vision the client have but didn’t elucidate.
A good way to confirm that you really get when the client means is to write down their requirements and then repeat it back to them for confirmation and to make sure you are correct. Ask more questions to clarify necessary data.
You must attend to the speaker, and then repeat, in your words, what you think the speaker said. This allows the speaker to determine if you really understood. If something is missing, the speaker can further explain the point. Usually when people feel that the other side listens to them, it encourages them to share more details.
When taking requirements notes make eye contact with the speaker, don’t multitask and do other things while listening to the speaker. Do not interrupt the let the other side finish what they say. Clarify the points that you don’t understand, and ask for more details if needed.
Summarize the conversation by organizing the key points and play them back for the speaker.
We are taught that is rude to ask personal questions. People will answer personal questions if they will get them what they want. People will talk all day long about their fears, wants, and frustrations if they feel it will help them to get what they want.
If some requirements or client requests don’t seem reasonable, you should question them. Something that might seem like a simple request from the client may be a huge commitment on our side. We should clarify this to the client and consider the benefit of the request in compared to the cost. Remember, in many cases the client don’t know what is required to develop a feature (this is why they hired you).
Identifying users is another significant component of requirements elicitation, and our program will make that process much easier as well. There are a few different types of users, and the ways in which they differ include: how often they use the product, what features they use, which tasks they perform for their business processes, their level of experience and systems expertise, and their security levels or access privileges. It can be helpful to classify users based on these differences. Keep in mind, though, that some people may belong to more than one class.
Also keep in mind that some users may not even be people. No, robots aren’t taking over the world – yet. I’m just referring to the fact that some applications or hardware components might be interacting with your system, and these could be considered their own class of users.
Other types of users to consider are indirect or secondary users. This group may not be using your application directly, but they might be accessing it through reports or other applications.
Think of as many user classes as you can and build your user class list. Look for groups that have similar needs – those can be considered a major user class with several subclasses.
Once you have determined your user classes, you will want to find user representatives for each class that can provide the voice of the customer throughout the duration of the development process. We’ve found that focus groups comprised of all types of users – both inexperienced and expert alike – are very helpful to the developmental cycle.
Role modeling steps
Use the following steps to identify and select useful set of user roles:
• Brainstorm an initial set of user roles – meet with the client. Each of the participants grabs a stack of cards from a pile placed in the middle of the table. Start with everyone writing role names on cards and then placing them on the table, or pinning them on the wall. When a new role is placed, the author says the name of the new role and nothing more. Since this is a brainstorming session, there is no discussion of the cards or evaluation of the roles. Each person writes as many cards as they can think of. Continue until progress stalls and participants are having hard time thinking up new roles.
At this stage, stick with identifying roles that represent a single user.
• Organize the initial set – now it’s time to organize the roles. Cards a removed around on the wall so that their positions indicate the relationships between the roles. Overlapping roles are placed so that their cards overlap. If the roles overlap a little, overlap the cards a little. If the roles overlap entirely, overlap the cards entirely.
• Consolidate roles – after the roles have been grouped, try to consolidate and condense the roles. Start with cards that are entirely overlapping. The authors of those cards describe what they meant by those role names. Decide if the roles are equivalent. If they are, they can be consolidated into a single role.
You should rip up any role cards for roles that are unimportant to the success of the system. We don’t need user roles for every conceivable user of the system, but we need roles for the ones who can make or break the success of the project.
After consolidating the cards, arrange them on the wall to show relationships between the roles.
• Refine the roles – once we’ve consolidated roles and have a basic understanding of how the roles relate to each other, it is possible to model those roles by defining attributes to each one of them. a role attribute is a fact or useful information about the users who fulfill it. Any information about the user roles that distinguishes one role from another may be used as a role attribute. Here are some examples:
o The frequency with which the user will use the system.
o The user’s level of expertise with the domain.
o The user’s general level of proficiency with computers and software.
o The user’s level of proficiency with the software being developed.
o The user’s general role for using the software.
Serving as an interface between the project’s requirements analyst and the members of each user class are Product Champions. They are vital members of the user communities, collecting requirements from members of the user classes that they represent. Product champs should be enthusiastic supporters of the new system and have a deep understanding of its benefits and its inner workings.
In the event that you are working in a situation where the users are unknown or otherwise difficult to engage, you may have to hire consultants or experts to be surrogates for actual users.
With all of these requirements issues being dealt with, and so many different users and stakeholders in the mix, there are bound to be lots of questions and conflicts arising, right? That’s why you must decide very early on in the project who your decision makers are for requirements issues. When no one is made responsible, then the decisions inevitably fall to the developers, and that really isn’t ideal since they don’t always have the necessary experience, knowledge, and perspective to make the best business decisions. So make sure every group chooses a decision maker right away, and select people who are well-informed on the issues.
For any project, there should always be at least one real user on the client’s team because real users are the ones who know how they need the software to work.
It’s tempting to think that we know what the users want, but no matter how smart we are (and I, for one, am very smart), the reality is that we can’t see the user’s point-of-view, so we really do need their input. Of course we know that sometimes it can be hard to get real users, in which case you need user proxies to represent them. The more user proxies you use, the better, since that makes it more likely that the system you create will meet the needs of a broader range of users.
As you proceed with requirements elicitation, you will find that requirements come from multiple sources, which largely depend on what type of product you’re dealing with. Sources of software requirements include marketing surveys, reports of problems, requests for enhancement of the current system, documents that describe industry standards, documents that describe competing products, events and responses, system requirements specifications, and analysis of user tasks.
During requirements elicitation, you’ll be getting a great deal of the information that you need through user interviews, but there are other simple techniques that you can use as well. Observing users while they interact with software is a great way to gain new insights. Questionnaires are helpful when you want to gather feedback from a large number of users. We’ve also utilized story writing workshops where users, developers, and clients all gather and come up with scenarios, and then ask questions like: “What mistakes might the user make in this instance?” and “What additional information does the user need at this point?”
Requirements elicitation should occur in cycles, with the first round capturing the highest level requirements needed. As the system grows, especially if it is moving in a new direction, you just may find that priorities change or new requirements are revealed. Fortunately our program makes it easy to set and manage these priorities so that your whole team will always be aware of changes.
Both you and the client have a major role in requirements elicitation. The person collecting the requirements, who we sometimes refer to as the analyst, should understand the client’s business vocabulary and become knowledgeable about the client’s business needs and objectives for the system. The information that the analyst collects should be structured into a written software requirements specification, which constitutes an agreement between the developers and the client regarding the qualities, functions, and constraints of the product being built. The analyst is also responsible for explaining the products created from the requirements process.
The customer should also be an active participant, helping the analysts and development team understand his business, taking the time to provide and explain requirements, and describing in detail how they want the end product to function. The customer needs to collaborate with developers in determining priorities, functional requirements, system features, and use cases, providing information in a timely manner and respecting the developer’s cost and feasibility assessments. If the customer requires changes, they should be communicated as soon as possible, following the developer’s process for requirements change requests.
The heart of the matter is that there must be respect and professionalism between all parties involved in the requirements process. If everyone is open to all ideas, prepared to set priorities, honest and fair about costs and impacts, and communicative about needs and changes, then you will be on your way to building the product that the customer desires.
As you can see, this process of requirements elicitation is absolutely crucial because you can’t design a system for your client until you completely understand what problems it needs to solve.
During the requirements elicitation process, you’ll be taking in a lot of info, which should be categorized so that you can document and properly use it when needed. So let’s go over those categories now.
A Business Requirement is anything that describes a financial or business benefit that the customer hopes to gain from the product.
The business requirements represent the top level of the requirement chain. They define the vision and scope for the system. The other requirement types must align with the context and objectives that the business requirements establish.
The scope draws the boundary between what’s in and what’s out. It defines the project’s limitation.
The vision applies to the product as a whole. The scope relates to a specific project that will implement the next increment of the product’s functionality. Scope is more dynamic than vision. It includes the content of each release. The vision includes all the different scopes.
Business requirements describe the primary benefits that the new system will provide to its sponsors, buyers, and users.
Functional Requirements describe behaviors that the system will show under particular conditions, as well as the actions that the system will allow users to take.
User Case and Scenarios are general statements about user goals or business tasks that users must perform. One specific path through a use case is known as a usage scenario. You can find out use cases by asking users what are some of the goals that they have in mind when they’re working with the system.
When a client specifies that only particular user classes may perform an activity under specific conditions, that is what is known as a Business Rule. Business rules are not functional requirements, so you may have to define software functional requirements in order to enforce these rules.
Statements that explain how well the system performs a certain behavior or allows the user to take certain actions are called Quality Attributes.
Then you have Data Definitions, which include definitions of data type, default value, and allowed value.
Constraints are what restrict the developer’s options. Take note of the reasoning behind each constraint so that everyone working on the project knows why it’s important.
And finally there is External Interface Requirements, which describe the connections between your system and everything outside of that system. Whew, that was a long list! But now you have the inside scoop on what requirements elicitation is all about. Obviously it’s an incredibly important process, one that you’re going to want to implement in all your projects right away. You’ll find that our new program streamlines it for you and makes requirements elicitation an absolute breeze.