Stakeholders

These are the people and organizations that directly or indirectly affect the system requirements. You will spend the most time collecting requirements with them. In some cases, you may collect more candidate requirements in documents, but that will take less time to do so. That will become clear when you examine each technique.

Documents

These documents contain information important to the system that can contain requirements. Legacy system requirements documents, concepts of operations, policy documents, architecture documents, or anything that influences the system in question are important.

System in Operation

This could be the legacy systems (not always fully automated), predecessor system, or even competing systems; these all could influence what requirements apply to the system in question.

Next, we will introduce the technique overview mentioned earlier.

Facilitated Session

TechRepublic defines a facilitated session as a group (five or more) for a common purpose. This approach is faster than if you were to interview each user separately. By this definition, it could belong in the interview section. It is presented here because of the source’s definition.

Focus Group

A Guide to the Business Analysis Book of Knowledge (Third Edition, IIBA 2015), also called the BABOK Guide, defines a focus group as a gathering of people who are representative of the users or customers of a product to get feedback. You can gather feedback about needs, opportunities, and problems to identify requirements, or you can gather feedback to validate and refine already elicited requirements. This type of meeting happens quite often especially if you cannot easily call together a larger group of users given the size or amount of time that can be devoted to the effort.

Joint Application Development /Requirements Workshop

A JAD, sometime called a requirements workshop, is a meeting to collect business requirements many times associated with a prototyping development methodology. JADs usually meet until the session objectives are completed, sometimes taking two to five days. For a requirements JAD session, the participants stay in session until you document a complete set of requirements and the stakeholders agree. Sometimes, you may create domain-model artifacts (like static diagrams and activity diagrams) to facilitate this process. You will examine these models in Chapter 12, not here .

For some meetings, you may want someone who runs the meeting and another who captures the data provided (aka scribe). The reason for this is that the facilitator can concentrate on running the meeting and keeping it under control. You will find that it is difficult to both run the meeting and capture all the notes from the discussion.

The biggest challenge, even though JADs/workshops can be very effective, is getting people to commit to this approach. Asking many people to stop doing their day-to-day job for days is asking a great deal. It may be one of the fewest used elicitation techniques because of this. It is strongly recommend that you do this away from the normal office and do not allow outside phones to interrupt the workshop. Some crisis may arise that may cause someone to stop participating. However, if people cannot get onto the network or check their voice mail at every break, you can have breaks end on time. Some people recommend that you have a workshop at an offsite location where people do not go home at night in order to encourage additional discussion among the group and so people are less likely to get distracted. This happens even less often than the workshops themselves, again from both a cost and time investment. This is something you need to consider.

For any type of elicitation meeting, not just JADs, you need to keep people on task, especially if the schedule is tight. Some groups may wander a bit on the topic and that may be OK, but it is a judgment call as to how long and how often it happens. However, maintaining focus is critical to accomplishing the goals and not losing participant focus. It is frustrating to devote time to this sort of effort and watch the conversation wander all over the place.

Support Teams

EPF recommends talking to support teams. This is not a new kind of meeting, but you want to meet with these types of people to talk separately from your general system users. You will have to decide whether this meeting is just an interview session (which will be presented shortly) or whether it is one of the other meetings that have been discussed in this section. The help desk, the system monitoring, system auditors, trainers, and even DBAs and those who deploy the system can be candidates for these meetings. Remember when these types were talked about at the beginning of this section?

One reason to meet with these people separately is that the other users may not care about one group’s needs. For example, someone who audits the system for security reasons does not care about what the help desk needs, and people monitoring the system will not have the same needs as those who deploy the system. In fact, if some of these groups meet together, they may argue that other people’s needs are wrong because they are not theirs. Hypothetically, auditors say that people monitoring the system for availability takes away from the audit function that collects data on who accesses the system and therefore system monitoring should be eliminated. You want to avoid such discussions. While they may not always happen, they can occur, and you want to mitigate the likelihood of them.

While the types of people and their associated needs may be unique to their responsibilities, the approaches to gather them are virtually identical to any user, such as interviewing them for their needs. Many times, their needs have been consistent over time, and they make an excellent start point by describing them. Additionally, look for the things they would like to have but do not. The next section discusses a good technique to support these user types.

Brainstorming

Last among the group meeting types is brainstorming. This is one of the more free-form and, frankly, fun approaches for eliciting requirements—well, at least for the ideas. The requirements come later.

The purpose of the session is to come up with areas that people may not have considered-. Here are steps to consider for the brainstorming session:

1. For each session, define the particular topic to explore.

2. Let the people identify as many ideas as possible.

3. Do not be limited by known technology, budget constraints, security restrictions, policies, and so on.

4. Do not criticize the goodness of ideas or debate whether they are practical.

5. Once all the ideas are captured, then refine and combine them (that’s your job) to get joint agreement.

This brainstorming process can be a precursor to prototyping. Prototyping is trying various approaches, especially dealing with how something may look on the screen for software. This way, you can experiment with some of the ideas generated from brainstorming. You may want to prioritize the ideas collected, so you may better understand which may be the most important to consider. If the users say that something really works badly, that is something to look at first potentially.

Even though brainstorming is designed to stretch thinking outside normal silos or constraints, sometimes it doesn’t capture everything. This reinforces that you should do the preliminary research as described previously. Also, to help fill any gaps, you might want to consider other techniques to find all their needs, as in this next section.

Size of Interviews Vary

You can interview users either one on one or in small groups. Several factors drive you to one or the other. The number of users may be very small, so only one may be available (e.g., a database administrator). If there are only two or three, you may get the chance to talk with only one of them. Alternatively, management may give up only one person from an organization to talk with you because the manager cannot afford to give up more time. Other times, you have the ability to talk with more than one person in a particular part of an office.

What is the ideal number for a group interview? Two to four is very good because you do not have too many people talking at once, and the people probably have similar responsibilities. However, as mentioned, you rarely have the choice. If you have five or six, that is workable. As you get larger, people can sometimes feel like they are wasting time. Why? With only one person talking at a time, that means everyone else is sitting there essentially doing nothing. If you have 12 people, up to 10 people may not be engaged. Also, in larger groups, some folks will tend to be reticent and contributions can be lost. Therefore, the number of people is a balancing act. Of course, you have this issue with any meeting (as mentioned in the previous section). If a chief of an organization wants an entire team there, you can offer two sessions, but if the chief insists, it is their call to make.

In-Person, Telephone, Videoconference, and Online Interviews

Here are the typical formats for performing interviews:

• In-person

• Telephone

• Videoconference

• Online

Many interviews performed face to face also called in-person. This works when you are more geographically localized so that you can meet with the people. This has the distinct advantage of seeing the people more directly, so you can pick up on nonverbal clues easier. Also, you may have a bit more flexibility to run over if need be, which telephone and videoconference may not have.

There is also the phone, but it happens without the benefit of nonverbal cues. These cues can help to reinforce points, like how unsatisfied someone is, or when someone has a confused look on their face, you may need to either rephrase your question or ask some probing questions to see why they don’t like something. Phone interviews are more difficult but may be necessary when users are remote.

If you have the ability to video teleconference, you essentially come back to having a meeting but with the added need to watch the screen for nonvisual clues. Having more than one site on a screen may preclude you from getting good nonverbal clues, so pay attention. Depending on the reliability and throughput availability, you may have some limitations on resolution. However, as technology and bandwidth improves, these impacts continue to lessen. The size of the room and how good the sound capture is can impact how well you hear, so be aware of that. With an in-person interview with a larger group, more than one conversation may be a minor irritant, but with videoconferencing it is even more important to maintain good speaking discipline or you may miss important information.

Doing an online interview is more like a questionnaire than an interview, and you learned about that earlier. Also, you could have a much smaller group of people and send more open-ended questions.

Segregate by User Roles

When you do have groups, it is highly recommended that people with common needs be together. By that, if you have organizations with different focuses for the system, they may say that each other is wrong about the needs, when in fact their missions are different and hence have separate needs. Database administrators focus on maintaining the database, whereas the HR representatives are querying the personnel data regularly. Each type of person has different tasks, and you should talk to them separately. In addition, the DBA will likely be bored when HR is talking about their issues, since the DBAs are much more technical than the HR user. In addition, the HR users will likely be confused by the technical aspects that the DBAs discuss.

Running an Interview

How do you run an interview? Whether it is one or a few more people, there is not a significant difference. You basically ask questions about what the user does. In this respect, it is like the open-ended questionnaire. Ask them questions that will give them freedom to discuss a topic. What questions should you ask? As you would expect, the answer is that it depends. What kind of system is it? Is it a software application like the FBI Record Management System or a collection system like the BOSS Radiation Dosimeter System?

Ask what they do and then why they do what they have said, not how they do it, but why, so you understand if it is still necessary. A different design might obviate some of the steps user do. For example, having a concept search that can take name variations like Bob instead of Robert or accounting for different spellings of Mohammed will mean that users do not have to spend hours designing the right Boolean search to capture the information they need.

Ask the user how often they perform an operation. Get ideas for how long certain operations take (say, research results within the database.) What works well, what does not, and why? Have them give examples of their typical operations, explaining deviations and why. Ask questions as you go along. If you need them to slow down so you can write down everything, do so. At the end of the interview, ask if it is OK to ask follow-up questions. These follow-ups do not have to be in person. It could be on the phone or in e-mail. It is recommend you use e-mail because then you have their description in writing, you can save time capturing the requirements, and you are less likely to hear it incorrectly.

When you have a lot of ground to cover on a system, sometimes it is useful to break the discussions into topic areas so that you do not try to cover everything in one sitting. It is easier to do four two-hour interviews than an eight-hour day continuously. It is hard for you to concentrate for that long, and it is even harder to get users to give up an entire day. Spread over several days, or once a month if you are doing different functional areas, this works out better.

As was mentioned, interviews work better when everyone present is at the same level or has the same role. This is part of your preparation to ensure whenever practical that this is the case. If the people are managers and their subordinates, the subordinates are less likely to disagree with the manager who may speak the company line or talk about the ideal system when they do not have to use it every day. That can be as important as preparing your list of questions you want to ask.

Remember when Chapter 1 talked about the attributes of a good requirements engineering being communications, including listening with emphasis on active listening? It is during interviews (and any meeting for that matter) when you need to do that. Listen with your eyes and ears. Look for the nonverbal clues that give away some emotion. Do you see people reacting negatively to statements? Follow up on that. Honestly, that is where you can find some of the most critical aspects, because that alluded to the items that most bothered the users .

Your level of formality may even vary with the users. For example, if you are talking with managers, especially high-level managers, you may be more formal than you might with users who do not interact with these people as much. Sometimes you may have a more structured set of questions because the topic is broader than others are. For example, with searching, it might be more free-form, whereas when asking about all the known reports, you will have one or more questions for each of several dozen reports.

When you have looked at employee suggestions (later in the “Document Analysis” section of this chapter), which reinforces the interconnectedness of these topics, now is your opportunity to ask why they were added. This shows that you cannot go into these interviews cold. In other words, you cannot do this on your first day. You need to know something about the current system, the terminology, the user employee, and what their general goals are. One of the best sources for this foundation is discussed in the “Document Analysis” section coming shortly.

People often use things for purposes for which they were not designed. You can learn a lot from this.

Things That Enhance the Interview

Chapter 1 emphasized the importance of good communications. Interviewing is probably the biggest manifestation of that skill. Remember, no matter how long you have worked on a project, there are people who know more about the project, at least some aspect of it. Therefore, a know-it-all trying to get information from a user will fail—miserably. You need to establish trust and a rapport with the users. If a user says the radiation dosimeter takes too long, don’t tell them they are wrong. Ask them why it takes too long. It may be that the performance requirement before said that the result should return in 10 seconds. To most users that is way too long. Maybe you are unaware of that requirement, or it may be that the device they have is not even meeting that requirement. Maybe when the battery gets low, it takes a minute to get the result. Never reject a person’s statement. If it does not make sense, ask more questions to understand. Usually, you should go back to the people responsible for the system and find out what is happening. Occasionally, developers were unaware of issues you discover. In many cases, you can find out there was something wrong, and you can get it fixed.

Go in with an open mind. Think of the users as the teachers and you as the student. There is a reason why they have information you need, so try to learn from them. Be a human being; admit that you do not know everything and that the users can teach you. After all, your reason for collecting their needs is to help the users get a better system in the future.

Business Process

If you have one or more business process analysts on your project, then you have someone who has or is doing a business process analysis of the system or area for which you are going to capture the requirements. This is excellent. If you do not, you should definitely consider creating one.

Why do you need this business process description? First, you need it so you understand what your current system is trying to do. As mentioned earlier, if you are new to the system, then this is an excellent method to learn about the system. Certainly, it will not give you everything, but it is a significant start. In addition, when you look at the existing requirements, you need to find where things have changed and learn what the gaps are. Sometimes, all that exists are diagrams that describe the system at a high level or PowerPoint slides that talk briefly about the current system. Remember, no information is bad if it provides a starting point.

As was said, you can even use the business process description document to generate the user stories for a system. More information will be presented about user stories in Chapter 13.

A business process description document can also be called a concept of operations. Many times a CONOPS, as it is shortened to, is written before the requirements phase begins. If so, that is good as you have the start of your work. In addition, the advantage will be that the CONOPS is written for the future system, whereas many business process descriptions may focus on the current system. A word of caution: while most CONOPS are written near the beginning of the lifecycle development phase, some are written near the end. Is this because the project is behind in doing their documentation? That’s possible, but more than likely there is another cause. In most instances, the project is doing the CONOPS with the emphasis on the concept. By that, they are looking at the functions the system should do and be talked about at a higher level. In the later phase of the lifecycle, you may see where the emphasis in the CONOPS is on the operations. What you have here is an operations manual. While this is a useful tool, that is not the focus of this paragraph’s discussion.

Notice that some elements of the CONOPS may have proposed implementation that you should discount. In addition, it will not be detailed enough to fully capture requirements, so you will have considerably more information to complete your requirements.

Existing Requirements

First, look for requirements for the existing system. This will likely provide a significant amount of information about what you should consider. Remember, however, they were crafted in a different time, with different technology, and, most importantly, with different expectations. You do not have any context with these requirements unless there is significant textual information added to the shall statements. You do not get a significant sense of how the requirements must fit together, or flow. You will need to gather that elsewhere.

Most importantly, you will need to ensure that all the requirements are still valid. Given the scope or size of the project, that may prove to be daunting. Nevertheless, it needs to be done. For those items you have changed, modify the requirement set. Modify the existing statements for those that have changed somewhat. For those no longer done, delete them (but confirm with stakeholders that it is true), and add what is new.

Existing Interface Documents

This is essentially the same kind of documents as the requirements documents, just between two systems. There is one important aspect to consider with interfaces—the boundaries may change with the new system. By that, some items that exist in other systems may come under your system’s umbrella, and vice versa. So, do not take everything as gospel without the same validation as was talked about in the previous subsection. Make certain the boundary of your new system is well defined.

Design Documents

Design documents, when they exist, do not provide nearly the same information as a requirements document, in part because they focus on the implementation, which requirements engineers are not supposed to capture. That said, there still is useful information embedded in them. For example, you might learn what data elements are being stored and manipulated, what data is audited, and so on, basically topics that may not be defined or only partially defined elsewhere, like the existing requirements. There is a lot of chaff to weed through to get the wheat but that is still worth examining.

Manuals: User, Operations, Training, and Help

These manuals can prove to be very useful, with qualifiers. They are designed to describe how the system should be used, and they are very detailed. When gap analysis is talked about later, these documents may suggest areas that have not been fully explored.

The qualifiers deal with the following:

• These are details about the exact steps to take when using the system. However, it may not explain why you would do these steps.

• These are the current implementation and may not be appropriate for the future.

• In addition, they are implementation, so again you need to determine what functions should be retained.

Identified Problems and Changes

Another source for requirements for the system can come from user suggestions, RFCs, change requests (CRs) , discrepancy reports (DRs), and problem reports (PRs) . These documents (whether hard-copy documents or online) are likely the items that have changed since the original system was implemented. Many if not most may be specific changes to the implementation rather than just user needs, so examine them carefully. For example, someone who asks for the status of a current operation moved from the bottom of the screen to the top is not a need but more a user preference. However, it may indicate that the users need the capabilities to customize the user interface, or at the very least allow them to specify some preferences.

Sources may come from the configuration management process your organization has implemented, called the following:

• Request for changes

• Change requests

• Discrepancy reports

• Problem reports

DRs and PRs may be the same thing, just defined differently for various projects or organizations. In addition, RFCs and CRs may be the same thing just using the terminology of the office.

Most people define an RFC or CR to be the documentation of changing a requirement, adding or deleting a requirement, or modifying an existing requirement. A DR or PR is when an existing requirement is not working correctly.

Also, check the Help documentation or service desk. Even if the item never causes something in the application to change, it may indicate items that seem to cause problems for the users, showing you places to improve in the future. This can also be a source of user suggestions that has not yet made it to the configuration management system.

Competing or Analogous Systems

If your project is to create the best report generator ever, wouldn’t it be prudent to see what other report generators have done and done well to ensure you capture those capabilities at a minimum? It’s not likely you will work on something that has been worked on for many years, but you get the idea. Look at other systems and determine what capabilities you might consider. They could be competitors or systems similar to yours.

You do not need to “reinvent the wheel” for each project. Do it once, by researching what is available, and then reuse. However, I emphasize that the Internet is an excellent source of capabilities.

Defining the Scope of the System

First, you must define the scope of the system . You need to know precisely where the system responsibility begins and ends. Ideally, you receive this at the start. Alas, the reality of it is that this does not always happen. So, you will need to help define these boundaries. Will they remain fixed? Not always. For example, if the new system will be follow an SOA, some small systems/applications that were stand-alone systems before may be services as part of your new system. In this case, the boundary of the new system has expanded beyond what may have initially been proposed. In such instances, the boundary definition may change because of what you uncover in your elicitation that others had not considered. This gets to how requirements change. Analysis forces people to make decisions they had not even known about initially. That is a good thing.

Gaining Domain Knowledge

Second, if you do not have full domain knowledge of the current and future systems, get it. Yes, that is easier said than done, but go back to the “Document Analysis” section and use that as a guide for starting that information gathering.

If you do not have a good BPD, then create one yourself. By virtue of you doing this, you will learn it better, and it can have additional benefits later in the requirement analysis process, as you will see.

What you will have when you are finished is basically a concept of operations but clearly focused from an implementation-independent view. Even if the users have some of the BPDs, you will need to go back and ask questions to fill in the gaps of knowledge. Odds are that if you do not understand the BPD, there is a gap in knowledge, or the business process has been changed and not properly documented.

Deciding On the Elicitation Techniques to Use

Once you have gained sufficient knowledge, you can begin. The reality of this is that, in many cases, management will determine when to start, and you try to gain as much knowledge as you can before the step starts.

An earlier subsection talked about using document analysis to start eliciting requirements as part of gaining domain knowledge, but it does not end with that, as was talked about before. Which technique do you use? The correct answer is more than one. Each has its advantages and disadvantages. To mitigate the disadvantages, you want to use as many as practical.

What factors should you consider in determining the techniques?

• Who are the stakeholders/users? (For example, if this is a commercial game, who represents the consumer, and how?)

• What is requirements engineering team domain knowledge?

• What is the availability of stakeholders/users?

• What is the location of stakeholders/users?

• What is the development team’s domain knowledge?

• What is the stakeholders/users domain knowledge?

• What is management’s commitment to eliciting the requirements?

• What is the schedule for eliciting the requirements?

• How big is the requirements engineering team?

Then you, and your team if you are part of or lead a team, must decide which techniques to use. Consider document analysis, interviews, and some group meetings. Use the others that have been discussed as you and your management team see fit. Trust me, management commitment here is absolutely essential or you will not have access to the people you need. If you have to get it, start with your management chain. If they cannot get agreement with your approach, you will have a hard road ahead of you, with less likelihood of success—to be quite honest.

Eliciting the Requirements

Now comes the challenging part, eliciting the requirements. Before you actually start, a bit more planning is in order. If you are likely to have more than 100 or 200 requirements, one session is unlikely to capture all the requirements. Your best bet is to take this larger program/system and break it into manageable chunks. You may need to apply most of the techniques to each functional area that you choose, or maybe by the team/organization that is affected by it. For example, the auditing team will work only on the audit function.

One additional suggestion is related to the functional area elicitation. The document analysis mentioned earlier can help establish many or most of these functional areas.

You will need to massage the information you collect. Remember, users do not speak requirementese. You do. You need to translate their input into good requirements, as has been discussed in all the previous chapters.

To define all the requirements, you need to understand what the users do right now. This is an important point to remember: it’s not how they do it, just as good requirements do not define the how and only the what. Get them to tell you what they do.

You have to listen intently. However, know that they will skip over points. This is not intentional, but they know all what they do, and they do not include every little nuance. It is human nature. Part of that happens because they assume you know everything they do. Part of it is that they summarize. They are not accustomed to providing every step they do. Think of a user manual that describes how to do a new feature where the document describes every step, every keystroke, every click that the user must do. Most users do not think quite like that when they are talking. In fact, it is difficult for most people to do. If someone asked you to describe how you drive to work or school every day, would you give every street name, the distance, and the time associated with each step? More than likely you will say, “From my house I go two blocks north and turn left at the elementary school, through three traffic lights and turn right….” Many details are missing that MapQuest would provide. It is your job to learn the MapQuest “route” from the users rudimentary “directions.”

If going from step 1 to step 2 does not make sense to you, chances are they have omitted something. Sometimes it is language or jargon that you do not know, and the missing information may be embedded in those words.

Think about signing into an application on a network. Someone is describing what they do when they first start their machine and get to this application. They say the following:

• First, I turn my machine on.

• I hit Ctrl-Alt-Del to log in.

• Then, I select the BOSS application.

• Finally, I run my audit report from the log of updates since yesterday.

That initially sounds like it is sufficient. However, the user did not give specific details about how they logged in. This is a system administrator, who has multiple networks to monitor. When they log in, they have to enter their user ID, password, and what domain they are examining. Because they did not give these specifics, you might miss that the login process requires the domain value. You need to ask them what they mean by logging in. Then ask what the domains are that they access. Can domains be added and deleted, or will they remain fixed? You get the idea.

Remember, Chapter 1 talked about the two different definitions of recall. The development group used the word to mean removing a bad record from the database. However, the people who would use the new system used the word to mean calling for a group of hard-copy documents from the archive. Think of what happens in a meeting the first time this comes up, and one group uses the recall with their meaning, but the other group of people hear that the use of it and cannot understand what was said because the meaning was “wrong” in their mind. This is going to happen. How do you know? This is where you have to observe. Sometimes people may challenge, but more often or not, people will just look confused. Not only do you have to listen, but also you have to watch, especially body language, facial expressions, and so on. Use anything that will give you an indication. In poker, this is called a tell—an indication that what the people are trying to indicate is not quite correct.

Reading requirements does not address how they flow or how they interact. The business process description shows that. If you understand that process better, you will have a better foundation for defining the requirements.

Then you need to show what you have captured with the users/stakeholders to confirm you translated it correctly. You will receive some pushback because they want their words exactly used sometimes. You have to explain the rationale for why you do it the way you do.

It may take more than one review to get concurrence. Remember this is a negotiation. You are not a dictator. Sometimes, managers will overrule some decisions, and you will have to live with some of those decisions if you cannot get your own management to stand up for it.

Performing a Gap Analysis

You are not done yet with collecting requirements. You have a challenging step to do. You have to find what everyone, including you, has missed. You might say, “If you have not captured it yet, how do you expect me to do it now?”

It is called gap analysis. There are some steps to take. Go back to the previous requirements document, or similar documents, like user manuals and so on, and then describe what people are doing. Find out the functions that are talked about that have not yet been documented in your requirements.

For example, you find that they have not done auditing of the changes to the database. Find out specifically what they need tracked. Is it every data element within the database or just key values? Do they need all adds, changes, deletes to user accounts (probably in almost all cases)? What about tracking all failed attempts to access an account? It could be just someone messing up his or her password or user ID once and then getting it right. What about trying six or seven times? Is someone trying to hack it?

Remember when we talked about all the different functional and nonfunctional requirements? One of the reasons these chapters discussed more topics than most sources examined was to give you suggested areas to consider for gap analysis. Go back, and look at each type to see whether it sparks any subject areas that you need to fill in some gaps.

Talk to experts on the system and ask what topics they think were missed. These are probably people on the development team, especially the operations and maintenance (O&M) team that has been dealing with the current system probably for years.

Once you have identified the areas, craft the requirements. You may need to interact with selected users/stakeholders to help them validate these new requirements.

Completing the Requirements

What constitutes being done with the elicitation phase? If you have done all the steps up to this point, are you finished? Chances are no, you are not. First, ensure that you have done all the steps to include actually writing proper requirements, vetting them with the affected stakeholders, and finalizing them so they are ready to be maintained. Has your management identified that you are not complete until you have a database fully populated with approved requirements? Or must you have a reviewed and approved requirements document? Or both?

The key here is the approval process. You will likely have to vet the complete set (in parts or as an entire whole) through one final review with senior stakeholders and/or management. Your organization mandates this. If you must capture a requirements document, look in the appendix for a format, if your organization has not directed a particular template. Likely, some part of it may require some business descriptions. If so, the BPD talked about earlier will serve you well.

There is one last aspect, albeit important, to keep in mind. Remember when earlier chapters mentioned the likely growth/change to requirements of 1 to 4 percent per month? You need to consider that. You must have a method to update your requirements to account for this change. Ideally your organization will have a change management, aka configuration management, process in place. If not, you need to establish one for your requirements. This is necessary to control and communicate changes to all affected parts.

The Boundary of the System Is Ill-Defined

Not only was this talked about this earlier in this book, but also it was stated in the previous section that you must know the boundary of the system. This needs to be defined at the start of the project, and the major stakeholders must agree on the boundaries of where the system begins and ends. Not only will this include the major users, but people like the DBAs, architects, and other technical people should be included in this decision.

As was stated in the previous section, during elicitation you may find that the boundary may need to change. In this situation, get back to the same stakeholders who agreed upon the boundaries to begin with, and vet this proposed change with them. Once you have presented the suggested modification, then abide by their decision. You may have additional requirements to collect as a result of this change. If it includes adding significant new functionality, this may translate to extensive additional work.

Unnecessary Design Information May Be Given

It was reiterated from Chapter 1 and many times throughout the book that you must write your requirements independent of implementation. That said, there are some situations where architectural constraints will modify that edict. Thus, your only challenge will be in deciding when something is implementation or is a constraint. A clue is if a developer says, “How about if we try…”; then you know that is probably implementation. However, if the project architect says, “Our systems must all follow the SOA,” then you have a constraint.

Users Have an Incomplete Understanding of Their Needs

Of course, users don’t understand all their needs. Part of that is because they only see a portion of the system, that which they use. You can compensate by talking to a diverse set of users to ensure you get a broader perspective. In addition, there are certain key stakeholders/users that you must talk with to ensure you get complete coverage, such as the DBAs and system monitors.

Users Have Poor Understanding of Computer Capabilities and Limitations

It probably is not a great revelation that users may not know computer capabilities and limitations, nor should they. That is the job of the designers and developers to exploit. It is also your job to help clarify points to them when you can. For example, if a particular type of search causes the system to take considerable longer, if they know that, they may not default to that type of search. You can point that out when you are talking with them.

In addition, when the users are not familiar with newer technologies, like say machine learning, you can offer requirements that address more capabilities because of your gap analysis, with the requirements vetted through the users.

Analysts Have Poor Knowledge of Problem Domain

You were just transferred to a new program that you know nothing about, other than you initially hearing about it. Of course, you will not be an expert on the project’s domain. There are techniques for gathering that knowledge, like doing documentation analysis, especially the business process description. If one does not exist or it is not a good one, write one yourself. Do whatever you can to get yourself up on the learning curve. Sometimes it takes months, and not just one or two, before you become knowledgeable enough to understand much of what people are saying. Ask many questions.

User and Analyst Speak Different Languages

Most users are not computer programmers. They were not hired for that skill set. Therefore, you have to be aware of biases that some people have. Certain computer engineers and developers think all users must be very literate in computers, when they are not. There still are people who are almost functionally computer illiterates. They can do some things but get out of their comfort zone quickly and are extremely uneasy. Be aware of that.

The “Purpose of Elicitation” section in this chapter mentioned the recall example as one where the analysts and users had a different meaning for the same word. This happens all the time. That is why there is a chapter on jargon and language to help overcome this challenge. The best advice is to be cognizant of it and observe people when you are talking. Look for those clues when someone is confused, and follow up on it to see whether there is a language barrier.

Ease of Omitting “Obvious” Information

This is the trap that people assume a certain amount of information that everyone knows. That is one advantage to starting out as not being a full domain expert, as you will notice missing information and ask questions when you are confused.

Conflicting Views of Different Users

The previous section talked about this. Many times, this is because of different responsibilities, and you need to capture multiple points of view. In a few cases, you get wrong information from people. This is a bit more problematic. Here you have to find out which source is incorrect and eliminate it. It may be because the person does not know any better. You will have to decide whether you need to correct the person. The best way may be to involve the help desk to guide the person to the proper approach.

Requirements Are Often Vague and Untestable

Most everything focused on in this book has worked to eliminate the vague words from your requirements vocabulary. Trust me, when you get to a review of your requirements, someone will point out when you slip up. Just be vigilant when you craft your requirements, and after a break in time, review everything you have written and do a sanity check all of the good attributes against the requirements.

Requirements Evolve Over Time

Having a change management process helps because it gives a process for vetting those potential changes and how they might affect what you have already. Also, soon you will learn about the agile approach for requirements definition, which helps to mitigate the growth issue by capturing requirements close to when the development will occur so that the growth is then taken into consideration at that time.