Thousands of software projects are doomed from the start because they’re based on faulty understanding of the business problem to be resolved. Undoubtedly, requirements analysis is crucial for a project’s success or failure. It is universally acknowledged that one of the earliest and most important steps in creating new software is performing an analysis of the customer's requirements. Unfortunately, while clients know what they want the new software to do, they often have incomplete, ambiguous or even contradictory requirements. Thus, although some attempted solutions have been provided as results of continuous studies and practices, requirements analysis still tend to be a long and tiring process during which some import factors should be taken into account.
First, the requirements should be related to identified business needs or opportunities. No customer is willing to pay for a software system that cannot bring value, no matter how fantastic the software system is. As well, the new system will change the environment and relationships between people, or so called stakeholders. In order to fulfill the sometimes conflicting needs from various stakeholders, existing business processes are elicited for review, and what is more, they may be broken and then refactored. At the same time, interviews involving stakeholders are held so as to gather and go over the requirements.
Second, both developers and customers will benefit from requirements which are clear and easier to understand. Requirements stated by stakeholders could be ambiguous and inconsistent. It would be efficient and effective to describe them clearly in detailed information by visualization tools and natural language, so that both developers and customers are on the same page. Also relationships and dependencies between requirements from stakeholders with different points of view should be taken into consideration, to make sure that there is no overlap or omission. More importantly, it may be a good practice to check if there are any existing templates in hand which can save a lot of time and definitely reduce the possibility of making mistakes.
And finally, it will be great if the requirements can be actionable, measurable, testable, traceable, and defined to a level of detail sufficient for system design. As the output of requirements analysis, plenty of function points are summarized as a list. For example, in agile, we get some use cases in higher level, or stories in lower level. In any case, they must be something we can begin with. During the development processes, the status should be measured by numbers, so that actions can be taken in case there are any variances. At the end of each phase, testing work should be done to verify the targets have been achieved.
To summarize, just keep in mind that we should implement the requirements which can satisfy stakeholders by solving the right problem in the right ways.
Reference:
https://en.wikipedia.org/wiki/Requirements_analysis#Attempted_solutions
网友评论