There is a discernable difference between novice and veteran requirement writers. \u00a0The process is more art than science, but it\u00a0still has some best practices that can be of help to anyone. \u00a0Here are some points to consider that can help you make your next requirements document the best one you have written.<\/p>\n
In my experience, this is the most natural step. \u00a0Start with a high-level overview of needs for the project. \u00a0This helps set the stage for greater detail while providing a core design. \u00a0It is important to have this basic design as it provides a reference point as the details are refined that can help avoid drift. \u00a0Once this outline is created it can, and should, be regularly referenced during the definition of detailed requirements to ensure the details link back to core features.<\/p>\n
The highest level outline of requirements is the vision for the project. \u00a0The outline is the general view of what is to be created and drift from the vision is highly discouraged. \u00a0It does not mean the vision cannot be altered or refined. \u00a0However, a project is a plan for moving from A to B. \u00a0The B is the vision. \u00a0Therefore, changing B as the focus can create situations where you “take the scenic route” or even become hopelessly lost.<\/p>\n
<\/p>\n
Once the outline comes together, it is time to go to the next level. \u00a0This point is where most requirements fall apart. \u00a0There are a set of questions that a well-defined requirement will answer. \u00a0Let’s look at each one and what to consider in answering it.<\/p>\n
This question looks at how a requirement is executed. \u00a0It includes considering who can access a feature and whether it has limits for different users or times. \u00a0For example, an ATM has a requirement to dispense money. \u00a0To receive cash, someone must be authenticated to the system (card and PIN). \u00a0An authenticated user has made a request for withdrawal. \u00a0The account has been selected, and it has a balance greater than the sum to dispense. \u00a0Keep this example in mind as we look at the other questions.<\/p>\n
This question addresses the state or environment we can expect while fulfilling a need. \u00a0It potentially includes defining how the data is gathered in the first place. \u00a0Thus, we might find some more requirements to be determined while answering this question. \u00a0In the above ATM example, we should have an account number, an authenticated flag and an amount to withdraw. \u00a0Thus, we should have requirements defined that address how an account number is gathered, how to mark a user as authenticated, and how to tell the system what to withdraw.<\/p>\n
At this point, we define what success means for the requirement. \u00a0If we can not determine success or failure of a requirement, then it is either not needed or ill-defined. \u00a0For example, an ATM withdrawal results in cash dispensed and an account debited. \u00a0There may be new expectations as well, but they should all be defined as part of answering this question.<\/p>\n
The first question we asked is the entry to this requirement. \u00a0This question is the exit. \u00a0Once a requirement is fulfilled, we need to examine the options for proceeding. \u00a0Often the answer to this issue is a list of “locations” based on success or failure. \u00a0In the ATM example, we will show a success\u00a0message, an error screen, or might go back to the\u00a0main menu. \u00a0This step is where we might turn up some other entry requirements to define. \u00a0For example, is there a “quick cash” option that skips going back to the main menu and instead logs the user out after dispensing cash? \u00a0Alternately, is there an optional “print receipt” step to consider?<\/p>\n
This is the question most often missed in my experience. \u00a0Our vision is all about the\u00a0success of the system, but errors occur, and those must be defined as well. \u00a0In the ATM example, a user might not have a high enough balance to their account. \u00a0The ATM might not have enough cash on hand, or the dispenser automation might be broken. \u00a0The list of potential errors can get lengthy, but they need to be examined. \u00a0This long list can be simplified into an “exception bucket” that covers errors we can’t think of, but the more we tightly define the errors and corrections the more reliable the result will be.<\/p>\n
I see this question skipped more often than I expect. \u00a0Once a requirement can be considered a success or failure, does a notification need to occur? \u00a0This may be a report, a log entry, or any other communication method. \u00a0We might even want to provide multiple responses. \u00a0In the ATM example, the notification is likely a printed receipt (report), a beep or sound to note the process is complete, and a message on the screen. \u00a0Success is the most likely result to be communicated; it is the error communication that we often forget to define. \u00a0Do we ping a maintenance service if the cash on hand is insufficient? \u00a0Do we notify authorities if the authentication is a blatant fraud attempt? \u00a0These sort of error messages should be defined and are as important (maybe more so) as the communication of success.<\/p>\n
<\/p>\n
Defining requirements is an art form of sorts, but following some simple guidelines can make anyone more effective. \u00a0If your requirements have not considered and answered these questions then doing so can improve the likelihood of a successful project.<\/p>\n","protected":false},"excerpt":{"rendered":"
There is a discernable difference between novice and veteran requirement writers. \u00a0The process is more art than science, but it\u00a0still has some best practices that can be of help to anyone. \u00a0Here are some points to consider that can help you make your next requirements document the best one you have written. Outline the Requirements […]<\/p>\n","protected":false},"author":1,"featured_media":83,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"categories":[10],"tags":[4,14,9,15],"class_list":["post-82","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-special-topics","tag-best-practices","tag-design","tag-projects","tag-requirements"],"yoast_head":"\n