Please find below a transcription of the audio portion of Walter Stinnett’s session, Gathering and Writing Requirements, being provided by MPUG for the convenience of our members. You may wish to use this transcript for the purposes of self-paced learning, searching for specific information, and/or performing a quick review of webinar content. There may be exclusions, such as those steps included in product demonstrations. You may watch the recording of this webinar at your convenience.
Welcome to part two of the three part series on Project Requirements Management. In this presentation, I will be discussing the topic of gathering and writing requirements. Our lesson objectives are we are going to define the requirements gathering process and write well defined and properly structured requirements.
But before we begin the presentation, let’s take a look at some quiz questions and hopefully as I go through these and you’ll be able to answer them by the end of the presentation. The first quiz question is, what is a business need? What is a needs assessment? A completed requirements document should be? Elicitation is used to produce information relevant to a project by drawing out information from stakeholders, true or false? Which of the following is not a technique used during elicitation? Requirements should conform to which property to be well-written? Product requirements should be written to state? And which of the following is included in the needs assessment process?
Well, hopefully by the end of the presentation you’ll be able to answer those quiz questions, so let’s go ahead and begin.
What is a business need? I like what James and Suzanne Robertson says here. This is taken from their Mastering the Requirements Process book. They say that, “Requirement’s are not really about requirements. Requirements activities focus on understanding a business problem and providing a solution for it.” So, what is a business need? As you see here, it is the impetus for change in an organization based on an existing problem or opportunity. The need could be from your stakeholders, it could be from legislation from Congress or a strategic initiative from management.
A solution space is how that stakeholder’s need is going to be met. I like to look at the definition of a need as this: the gap between what is and what should be. The gap between what is and what should be. In other words, the gap is right there in there middle so we are going to have to find a solution for that gap so that we can move our organization from where they are to where they want to be. In systems engineering, the process of needs assessment is called mission analysis. That process focuses on the identification of the primary purpose of the solution, which is its mission. So, a mission is a purposeful action or task directed towards accomplishing a specific objective based outcome and level of performance. I like what Charles Wasson says in his book, Systems Engineering Analysis Design and Development. He states that, “Mission success requires insightful planning and solving the right problem with the right system at the right time.”
How do we determine the need? Well, we determine the need by doing a needs assessment. This is generally done to examine the business environment and address a current problem or opportunity. It is generally going to be requested by the stakeholder. It is normally the whole needs assessment in determining what the business need is, is often done as a precursor to the project charter. As well as giving a justification for the project, as well as afterwards, you understand what the product, service and result is or the objective of the project. Then you can begin to analyze how you are going to meet that particular need. But first, you have to identify what that need is.
Here is the process and we’re going to walk through just the whole needs assessment process here. First of all, you want to identify the problem or opportunity. What problem are we solving? What problems do our customers have that this opportunity will address? As you are trying to identify the problem or the opportunity, think not only about the need, but the opportunity as well. Is there an opportunity? Is there something positive? Is there the ability to gain more of a market share and so on like that?
But a needs assessment involves the completion of a gap analysis. During this first phase of the needs assessment, you need to determine what you already know about the organization’s needs. Whether it is to be additional resources, new technology, market expansion. It’s about figuring out where you are and where you want to be. You also need to discover other undisclosed needs that may be hindering you from moving from where you are or where you want to be. You’ll often rank those needs in the order of importance and then you’ll set the scope for your research. You’ll know based upon identifying the problem and/or opportunity, where to go in your research to eventually identify the actual need.
Once you’ve identified your problem or opportunity, then you begin to investigate that. There are a number of different ways that you can investigate the problem. You’re going to be collecting information that you need to better understand the gaps. You’re going to collect data. It might be from internal company records or it could be externally through market research techniques, such as surveys and analysis of secondary data, including statistical data. After all of that data is collected, it will be organized and analyzed.
Here’s some questions that you might answer as you are investigating that problem or opportunity. One: who? Who does the problem affect? Is it specific groups, organizations, customers? What are the boundaries of the problem? Organizational, workflow, geographic? What is the issue? What is the impact of the issue? What impact is the issue causing? What will happen when it is fixed? And what would happen if we didn’t solve the problem? When does this issue occur? When does it need to be fixed? Where is the issue occurring? Is it only at certain locations? Is it only with certain processes or procedures? Then finally, why is it important that we fix the problem? What impact on the business and the customer? What impact does it have on all of the stakeholders?
These are some areas where you can investigate and you can answer these questions to help you to further understand what that problem and opportunity is. Once you’ve investigated, then you can begin to gather relevant data to evaluate the situation. Once there’s an understanding, it is necessary to gather that relevant data to identify the magnitude of a problem and opportunity. Now, this is the key here. It might seem like you’re continuing to investigate and gather information. Yes, you are further gathering information concerning that need, but you’re going a little bit further here. You need to understand the magnitude of the problem or opportunity. This is known as sizing up the situation.
The lack of data can result in proposing solutions that are either too small or too large compared to the problem at hand. You need to attempt to measure the size of the problem or opportunity to help you to determine an appropriately sized solution. You don’t want to gather such information or have the lack of information, so to speak, that you can’t really know what the size of the solution is that you might need.
Once you’ve identified your problem or opportunity, you’ve investigated it, you’ve gathered relevant data so that you can understand the magnitude of the situation so that you can gather the appropriate sized requirements, now once you’ve done all of that and you know what that need is, then you can begin to draft a situation statement. A situation statement is a guide that will give you direction on what that need is. It answers the question, what is the problem that needs to be addressed? As you see here, there is a specific format that a situation statement should be written in. The problem or opportunity of A, has the result of B, with the impact of C. When you have a statement of the problem, it’ll be easier for you to set your objectives and the necessary steps or actions. It serves as a lighthouse to guide you and lead you in the right direction for what you need when it comes to finding the solution for that problem or opportunity.
Consider an insurance company. Like many companies, the insurance carrier took advantage of new technologies across its business and has an extensive internet presence. The organization wants to exploit mobile technology to improve its claims processing. Listen to this situation statement. The cost for processing insurance claims is rising steadily, increasing at an average rate of 7% per year over the last three years. The existing method of submitting claims either by phone or the internet, involves significant processing delays and has resulted in the need to increase staffing to process calls and personally investigate claims.
Now, if we take a look at the situation statement, what is the problem and what is the result of that problem and then the impact? Well, let’s take a look at it. The problem, I think, is the cost for processing insurance claims is rising steadily. The result is the existing method of submitting claims either by phone involves significant processing delays. And the impact has been the increase of staffing.
If you can understand what your need is and what the problem and you can write it out in this structured manner, it can help you to determine the direction you need to go to implement a solution for that particular problem. I like the quote that says, “A problem well stated is half solved.” In other words, if you can state the problem as well as you possibly can, then you’re already down the road to determining a solution.
Once you have the draft situation statement, then you’ll want to obtain stakeholders’ approval. You want to get agreement. This is a key step in this whole process because the situation statement is going to guide all subsequent work for assessing the business need. When this formal draft situation statement, the actual approval is skipped, it makes it difficult to determine whether the essence of the current situation has been captured. Stakeholders are very important, you need to get agreement, you need to make sure that the stakeholders agree with what you have said and that your situation statement is accurate. If it’s not, then you’re going to be guided down the wrong way if you don’t get that approval.
Once you understand what the need is, then you can begin the whole gathering of requirements process. This starts with a process called elicitation. Elicitation is the thorough discovery of business requirements. One of the reasons that this is so important here, is that requirements, especially from your stakeholders, may not be really readily available in the way and in the form that you want. Those requirements may not be documented anywhere, they might be residing in the minds of the stakeholders. Also, you may not be able to fully understand what the stakeholder is trying to request. In other words, it may be a little bit ambiguous what they’re saying. So you would need to clarify what those stakeholders are saying.
As it says here that elicitation is the discovery process used to bring forward or produce information relevant to a project or program by drawing out information from stakeholders and other sources. That’s the key thing here. Eliciting those requirements really is drawing out. You’re drawing out information from those stakeholders. For those of you who have children, you remember when they were toddlers and they began to form words. What did you do? You tried to draw out those words. Well, stakeholders are like babies. Just kidding, just kidding. But sometimes the information you need might need to be drug out of those stakeholders kicking and screaming.
This elicitation process is going to be highly cyclical. It’s going to be repeated multiple times for each level of abstraction in the system. Whatever the solution is, you’re going to have various levels of abstraction. To really properly gather those requirements, you need to have that information at each of those levels. As you see here, the elicitation process is performed iteratively with analysis to progressively elaborate the information. This is just a simple process. The whole point here is that you keep asking questions until you fully understand what those needs are, so that you can write accurate requirements for the solution to that particular problem or need.
How can you do that? Well, through a variety of tools and techniques, such as interviews, focus groups, facilitated workshops. Interviews, we all know what interviews, those are one-on-one interviews where you talk one-on-one with someone. This is the most popular type of requirement solicitation. It gives the analyst the opportunity to discuss in depth a stakeholder’s thoughts and to get his or her perspective on the business need and the feasibility of a potential solution.
You have focus groups. Focus groups consist of pre-qualified stakeholders who gather to offer their input on the business need at hand and potential solutions. These can be very beneficial when key stakeholders are not particularly imaginative or forthcoming. A few more vocal stakeholders may help them think through articulate solutions.
Requirements workshops or facilitated workshops involve gathering a previously identified stakeholders in a structured, facilitated manner. You’d pull everyone out from their particular setting, their work setting into a room and you lock the door and you don’t let anybody out until they’re finished. No, you don’t do that. But it is where that you have someone such as this picture, who is facilitating. Well, for focus groups you have a facilitator as well. But this is a type of workshop that is specific for requirements.
Where I work we’ve used this type of workshop that’s called the BMPP process. The BMPP process stands for Big Monster Piece of Paper. It is where you will have all of the stakeholders in a room and you put up a really big piece of plotter paper and then you use Post-it Notes. It is a brainstorming mechanism and you can bring in other documentation that can support your brainstorming for understanding your requirements.
But whatever form you might have to try to gather those requirements, you need a plan. An elicitation plan can be an important document that can help you to move through the whole process smoothly. Just like anything in project management, there’s a plan. A plan for this, a plan for that. These plans are used to guide you through the whole process of what you’re going to be doing and that’s the same here. It will allow you to clarify elicitation scope and really just organize the work that you need to do to elicit those requirements. As you see here, the information, what information to elicit. Where to find information, activities, how to obtain the information. Sequencing the elicitation.
Oftentimes what will happen is that the information that you are gathering, let’s say specifically for someone says, “Okay,” one of the questions as it says here. “How many employees will be moved?” Well, somebody could say that and give you an answer, but really that might be dependent upon another question. As we see here with the sequencing, that how many employees will be moved is actually the second question. But the first one is what is the physical layout of both buildings? Oftentimes, when you begin to ask questions, the answers that you get will lead to other questions. You just want to follow it through, but if you can think of as many questions as possible prior to going in, as well as who the source of those answers are going to be and the methods, then it’ll help you to really focus in and not go on tangents or anything. But allow you to really focus in on the elicitation process.
Here are some more examples of questions. For example here, as I mentioned here, is to determine what the questions are. Prepare them beforehand and you can enter those into the elicitation plan, as well as your objective. What is the objective of this elicitation meeting or interview or focus group? Having that objective will help you to focus on the types of questions you need to ask, as it says here. Agree on what equipment will be moved. The participants, the directors of IT operations, director of facilities, HR manager. Then you can begin to think about those questions based upon the objectives.
If you don’t have objectives, then you might be just all over the place when it comes to asking the questions. You might actually miss some of the questions that you really need to ask. So this just goes a little bit in depth more into the elicitation plan. You’d want to include the objective in the elicitation plan.
You’ve gotten to a point to where you are able to understand what the problem is and what the need is. Then you can begin to move on to the next process of translating those elicitation results into requirements. But before you do that, you need to confirm those results. This is where you are going to review these results with those stakeholders so that you can get stakeholder agreement, so that you can truly move forward. Those stakeholders are going to check for accuracy and completeness. They’re going to sign off on the results that you can move on. As it says here in the last bullet, the key benefits are validates stakeholders and elicitation results were understood.
All right, so we have a set of elicited requirements. It probably might be more answers to the questions written, not so much in the form of a requirement, but just written as just information, as answers to the questions. Now, once you’ve done all of the elicitation that you need to do to be able to have enough information to translate that information into requirements, now you can begin to start writing the requirements.
Let’s walk through this in this section on how to write requirements. You have different types of requirements, as we saw last presentation. But let’s be specific when it comes to personnel requirements. This requirement is in the form of responsible party shall perform such and such. You want to use the active rather than the passive voice and that’s pretty much the same for any of your requirements. It should state who shall, followed by a description of what should be performed.
Here are some examples. Budget officer shall create report comparing data between multiple offices, by funding source. Analyst shall enter FTE work hours in payroll system. You have the person who is the responsible party, they shall do something. In these two examples, create and enter.
For product requirements, this is similar. I mean, they’re all written similarly. In this particular instance it’s in the form product ABC shall XYZ. It’s going to state, as the personnel requirements, the product shall and whatever the product is going to do, followed by a description of what should be done. This is the key here when it comes to properly writing product requirements. You need to state what is needed, not how to provide it. In other words, state the problem, not the solution.
Here are some examples. The system shall operate at a power level of, the software shall acquire data from the, the structure shall withstand loads of, the hardware shall have a mass of. These are some good examples here. Of course, you’d need to finish them off for whatever it needs to operate, acquire, withstand or have. Personnel requirements and product requirements and really, when you look at both of these they’re written the same, with a little bit of difference there. Hopefully, this would be a good way to guide you in writing requirements.
Now, let’s walk through the requirements validation. What I mean by validation, I’m meaning that the requirements are written correctly. We’re going to go through that here. First of all, is the requirement written in an unambiguous manner? You want to use correct and unambiguous terms. There needs to be one correct understanding of the requirement. In other words, if multiple people look at the requirement, each of those persons should understand the requirements equally. Don’t use ambiguous terms, such as support, but not limited to, and/or, may, could.
For example, the stereo amplifier shall provide outputs for two additional speakers at full rated power. But this is the incorrect way to write that. The stereo amplifier shall support additional speakers. Well, additional, what does that mean? Does it mean two, three, four, five, 10? It really isn’t clear enough to really understand in an unambiguous manner.
Not only should it be unambiguous, it should be verifiable. Have you used specific qualitative or quantitative measures? Don’t use subjective or unquantifiable words that can’t be verified. It’s like in the previous requirement. Using the word additional is an unquantifiable word. When you are thinking about your requirements ask, “How will we verify or confirm the designed and built product met the requirement?” Here’s some other subjective terms you want to avoid: user friendly. What is user friendly? User friendly is really up to the user. They are the ones who are going to determine whether that is a friendly system or friendly action. That’s really subjective. Adequate, don’t use clearly or other words that end with LY or IZE.
Here are a couple of examples. The system shall update the display every 10 seconds. That is the correct one. The incorrect: the system shall have a fast update to display. Fast, what is fast? It’s really unverifiable, you can’t really determine because fast might be in somebody’s mind a certain speed and it might be another speed in someone else’s mind. Unambiguous and verifiable.
Thirdly, traceable. Is each requirement uniquely and correctly identified? Now, we’re going to get more into requirements traceability. We’re going to look at, I was about to say, requirements traceability matrix. We’re going to look at that, but in the third presentation we’re going to focus in on traceability. We’re going to look at some examples of requirements traceability matrix. Really, this is the characteristics of a requirement being traceable. Can it be uniquely and correctly identified? Is each low level requirement traced to a high level requirement? What about lengths between requirements and information and other documents?
In a traceability matrix and in general, when you are writing the requirements, remember I mentioned earlier about eliciting those requirements at every level of abstraction. What are the children elements? Do the children elements aggregate up to the parent element? If there is something missing or if it really doesn’t aggregate up, then they’re not linked correctly.
For example, the parent is the system shall allow user to display a topology diagram for basins. And look at the child. The system shall allow the user to display a topology diagram to show the upstream to downstream connectivity of basins in a forecast group. As you see here, just as in a work breakdown structure, the parent elements are more general, but as you begin to decompose the elements down into children, then it’s going to become more specific. You will look at those parent child and say, “Can the child be traced back up to a higher level requirement? And can that higher level requirement be traced down to a lower level requirement?”
Then clarity. Your requirements need to be clear, consistent and written in a concise language. Just as the unambiguous, you want to ensure that more than one person understands the requirement. In other words, you want to for one thing, is to use the same terms throughout to be concise. You want to have some consistency with the language.
For example here, the first on is an example of a consistent requirement. The maximum vehicle net weight shall be two tons and the vehicle shall have two axles. And the inconsistent version is the maximum vehicle net weight shall be two tons and the truck shall have two axles. Now, look at this. The first one uses vehicle both times, but the second one uses the vehicle the first time and truck the second time. That is inconsistent because really are you talking about the truck as the first vehicle? Well, yeah, I mean, it mentions that there, but really is it the first one? Could it be a car are they talking about because it says here and the truck. Really, how do you read that? Being consistent is key to help people understand what that requirement is for.
Then readable. You want to use standard requirements terminology. Use simple words and phrases and concepts. Use shall, will and should correctly. If you’re going to be stating requirements, use shall if you’re going to be using the traditional way to write requirements. You see the example here. The ABS system shall illuminate a warning light in the event of and whatever the event of is. You’re going to use will in stating facts and then should for stating goals. As I mentioned previously with these requirements, you want to state what, not how. You don’t want to determine in the requirement or include in the requirement how it’s going to be done or how you’re going to provide it. It just states what is needed.
Here are a couple of examples. The XYZ system shall measure room temperature. But this is the incorrect version. The XYZ system shall use a four wire thermo-couple to measure room temperature. Can you see the difference here? The second one is showing how you’re going to do that. That’s what it’s included, but you don’t want to do that.
Let’s take a look at some, I guess you could say grammar. Touched on this a little bit already. Grammar, punctuation, sentence structure, those types of things. And specifically, we’re going to look at some problems that might be faced or that have been shown as maybe you’ve seen these issues and these problems as you’ve reviewed requirements. But the first problem is overly complex sentence structure. You’ve got multiple clauses, interrupters, you’ve got misplaced and dangling modifiers and unnecessary repetition.
For example, the GUI, based on the Linux interface, but compliable to Windows and Mac OS versions 97 through 2002… You can tell that I probably should have updated to the latest operating systems. The GUI, based on the Linux interface, but compliable to Windows or Mac OS Versions 97 through 2002 and to encompass version 10, should allow the administrator or other user with similar access attributes to create new information, retrieve such information and subsequently edit existing information and save same to media, including but not to the exclusion of removable and permanent storage devices.
Huh, try to read that in one breath. It contains four interrupters and unnecessary repetition. That’s a lot, it really doesn’t make sense, it really sounds like some fine print in a contract. So you want to avoid this.
You want to use action words. Weak verbs are wasted word, while important activities are disguised as things. Let’s take a look at some examples of weak verbs. Make a determination, make a decision as to, give consideration to, render assistance. You could instead of wasting space on your paper by writing this out like this, you could use instead of make a determination, use determine. Instead of make a decision, decide. Then you see the other two, consider, help. It’s just a matter of thinking what is the most concise way to write these requirements that say what you want to say in the least amount of words that is direct and strong?
Noun strings. This is where you have a dense concentration of information that creates ambiguity. Noun strings are a series of nouns with no connecting words to clarify their relationships. For example, acoustic leak detection system or intelligence system advance information. What does that say? Is it a system to detect acoustic leaks, or a system that detects leaks acoustically? Is this an early information about an intelligence system, or is it provided by an intelligent system?
You see here that the way this is written, there aren’t any connecting words, you really don’t have anything that can clarify really what is this trying to get to? What is the purpose of this, so you want to be careful when it comes to nouns. You want to have the proper connecting words to clarify their relationships.
Grammar and spelling. How many of you have a hard time spelling? How many of you rely on Spell Check? Well, sometimes you can’t just rely on Spell Check, especially when it comes to cell phones. That Spell Check can send off some embarrassing things, but I digress. But it’s important here. Grammar and spelling errors create more than embarrassment; they detract from credibility and may create confusion or ambiguity. I think that is true really with anything. If you are having grammar errors and spelling errors, it can detract from your credibility. It shows you as less of a professional than you are.
Here are some examples. The system shall provide the capability to manage the system with a geographic and internet distribution of users. From an actual requirement document, first line, first table. The system shall provide the capability to manage the system with a geographic and internet distribution of users. Are the users going to be distributed across the internet?
This one, the patient was treated for abdominal paint, instead of pain. The system backup will be located on the lover level. That’s really funny, it should be lower. The individual solder shall carry two or more units. That should be solider. You’ve had the experience when it comes to grammar and spelling and how that can mess things up. This is something that should be reviewed. Reviewed by multiple people.
Here at the company where I work, we provide training and one of the things that we do is that we review all of our work. We have editors who do that and it’s very important before we actually send that out to whomever, before we teach it, to have that reviewed. It’s called quality, making sure that the process that we use one: is full of quality and that it meets requirements. Really, when it comes to quality in project management, that is one of the keys. Is that you are ensuring that the product is meeting those requirements that were originally set out for. That goes really into traceability and we’ll talk about that in the next session.
So be careful with grammar, really in anything that you do because it can make your requirements not clear, not concise, not unambiguous, nor readable.
Punctuation. This can always be a problem because depending upon how you punctuate, can dictate how the sentence or statement is read. As it says here, it causes ambiguity and confusion. For example, I leave all my money to Peter, Mary and John. Is that divided in half, where Pete gets half and Mary and John share the other half? Or is it divided into thirds? A comma would make all the difference.
Here’s another example. There are two on-site systems. The on-site system, which has the higher readings, shall be consulted in case of irregular readings by the mobile system. Does this mean that both of the on-site systems will always have higher readings than the mobile system? Or of the two on-site systems, use the one with the higher readings? If the latter, remove the commas. Really, where you put those commas can really dictate your understanding of what is being said.
Symbology, varying symbols or acronyms to mean the same thing and use the same symbol or acronym to mean different things. Here’s some examples. Seventy-eight degrees, 78 degrees Fahrenheit, all used for Fahrenheit temperature. Seventy-eight degrees, 28 degrees, that could be location, longitude, latitude and the temperature. Centigrade used elsewhere.
Here are some acronyms. How many of you have used acronyms? I think we all use acronyms in some way or fashion. But if we don’t spell those acronyms out, then there would certainly be confusion and misunderstanding. For example, ATM. It could meant automated teller machine, asynchronous transfer mode, adobe type manager, acetone toluene methanol, adjustable trigger mechanism. I think you get the point here. We need to write out any acronyms, we need to be careful with symbology that is similar and can be used the same way but have different meanings.
A user story is a requirement, feature and/or unit of business value that can be estimated and tested. It describes the work form the user’s perspective that must be done to create and deliver a feature for a product. It can be written as a type of user, I want some goal so that some reason and here are some examples. As a leasing specialist, I want the ability to upload an FS-81 document so that I can attach it to my lease file. As a content owner, I want to be able to create product content so that I can provide information and market to customers.
Now just as those traditional shall statements that we looked at, you also have quality attributes for user stories. It’s spelled out as the acronym INVEST. A lot of these are similar to what we just talked about. It is independent. In other words, it should be able to implement the stories in any order and still realize benefit. Negotiable. One of the big things with agile is adapting to change. Stories can be revised freely when better ideas are developed. Valuable. Each of the stories should in some way be relevant to the customer or user. Estimable. I had a hard time saying that, estimable. It should be possible for a developer with relevant experience to roughly estimate a story. We’re talking about estimating using relative sizing. Small. Big stories reduce opportunities for incremental testing and require more elaborate planning. Then testable. Testable, write tests allowing you to validate an implementation and delivers on your intent.
Once you have identified your requirements, you’re wanting to then resolve any conflicting requirements between the stakeholders. In fact, during this whole process of writing those requirements, you want to be communicating with your stakeholders along the way. Now, we’re going to talk about requirements traceability in the next session. You don’t necessarily start the requirements traceability matrix way after you already identified the requirements. You create that traceability matrix all the way in the elicitation process. You can update it as you go and you learn more information.
You want to write and prioritize business requirements, why are you doing the work? Then you want to create that requirements documentation. All of those requirements need to be documented in that requirements documentation and the requirements traceability matrix. You want to obtain validation and approval of those requirements from the stakeholder. Then once you get that approval, then you can baseline those requirements. We’ll talk a little bit more about baselining requirements in the next session because those requirements are going to be used to define the scope of the project, as we mentioned last week.
What about requirements document? Defines the requirements that make up a solution. It is used by the solution team to understand how to build a solution. They should be accessible within a tool, whether that is SharePoint, whether it’s in an Excel spreadsheet or any other type of web or desktop based application. And new versions of requirements should be communicated to the stakeholders. This requirements document is a living document. As you move through your project, there could be changes to the project. Therefore, you will have to go back into the requirements traceability matrix and update that. But you’re going to have to update the requirements document. This is all part of the monitoring and the controlling that we’ll get into next week. That needs to be continually updated. As you know more information, as you progressively elaborate through the project, then that needs to be updated.
A completed requirements document looks like this. It is unique and normalized. Each requirement is stated once without overlap. In other words, you shouldn’t have more than one requirement for each aspect of the system. You don’t want to have, for example, one requirement that states the functionality, but then you have another requirement that states really the same functionality, but maybe takes it a little bit further. No, you don’t want anything to overlap. All of the requirements are linked and complete. What we’re talking about linked and complete, they are linked to address the customers’ needs. All of those requirements, does it meet those needs? That’s where traceability comes in. You can look at the traceability matrix. You could have a column in there that has the business need so that you can check to make sure. Is it written consistently? Does it identify scope and context? And is it maintained by version control?
That is the process of gathering and writing requirements. Next week, we are going to be discussing monitoring and controlling requirements. If you have any questions, any comments, please don’t hesitate to contact me. I’ll be glad to help you in any way that I possibly can. Thank you for attending this presentation and hopefully we will see you the next time. Thank you.
Watch the on-demand recording by clicking here
