![]() ![]() ![]() So how do you stop making these mistakes? Simply by correctly segregating the information in the problem domain - concentrate on what the business wants the system to do. Okay, so what happens if you mix problems and solutions? Well, there is not a proper understanding of the issues, constraints are muddled and ownership is blurred. In other words, provide what the user wants not what the user needs. Requirements define the problem rather than solve of the problem. So, instead of "Do you have an Active Directory?", the question will be proffered as "What authentication services do you use?" The former will elicit a "Yes/No" response the latter will provide a deeper answer and provide opening for further probing. This document should detail all the needs of the customer, including their business processes and the issues that the solution will solve, automate or replace.Ī business analyst will ask open questions to draw out as much detail as they can. Without correct and proper requirements, the architect cannot design a solution that meets the customer's needs. Requirement gathering is the most important but most often least understood of tasks. Information on major design constraints.Background information and references to other relevant material.A description of the environment in which the system will work.This means the stated aims of the project. A statement of key objectives - a "cardinal points" specification.An executive summary of the requirements for management purposes.This document is the guide that will be used to drive the next stages of a project. On completion of the requirement gathering exercise, the vendor will deliver a document called the Statement of Requirements Document. If this is done correctly, the next phases are made significantly easier. A business analyst, however, will not be coloured by preconceived technical perspectives they will colour the information in a manner that a trained solution architect can use in the next stage of the process. That is not to say a technical person cannot do requirement gathering. one made to fit a vendor model rather than one custom-made to the needs of the business. A technical person will enter the conversations with a view coloured by their technical pre-conceptions this can lead to a "shoe horn" solution, i.e. This is wrong on many levels, not least of which is that a technical person starts thinking about the solution to be delivered and designed rather than concentrating on the requirements of the customer. What requirements gathering techniques should you use?Īll too often, technical people are tasked with the delivery of this section.Software requirements gathering techniques.More resources about requirements gathering: It is about mapping the current business processes and functions, the desired needs and requirements to enable a solution architect to deliver a high level overview of the design. This task is not a technical task but a business function. The second issue relates to the skills required for the task those tasked with the delivery of the requirement gathering exercise should be versed in business analysis. Remember, the requirement gathering stage is the first time, other than the initial sales pitch, whereby necessity dictates the vendor is on their best behaviour and only showing their best side. This also impacts on the customers' view of the vendor. This is the exact opposite of what should be done the customer not only senses this desire for haste but views the requirement gathering exercise as a waste of valuable time that's spent not delivering the solution. Subsequently, this leads to the vendor desiring that the requirement gathering process be done as quickly as possible. Firstly, a pre-sales team member is a cost-centre to the vendor and, as such, his time is seen as "free" to the customer but as an expense to the vendor. There are two main issues with the first major part of an IT project, which is often delivered by the pre-sales team in preparation for a formal bid. Issues with pre-sales teams and requirement gathering It is amazing the amount of projects that still start with a "back of a beer mat" design. The requirement gathering process is possibly the most important but most often least understood of tasks without correct and proper requirements, the architect cannot design a solution that meets the customer's needs. Without good requirements gathered during the interview stage, the rest of the design team and the subsequent implementation and delivery teams are working with one hand tied behind their backs. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |