Developing software solutions is no easy task. It involves that the developer must understand the problem, know the technology and implement a solution – in the shortest time possible, possibly written with the latest technologies and methodologies and with the least amount of bugs and implemented in a user-friendly way, if possible requiring less training and documentation. So, here comes the analyst.
Requirements elicitation, or rather, the practice of obtaining the requirements of a system from users, customers and other stakeholders [1], is in itself a science and an art. It involves understanding people, understanding the domain [2], understanding the technology, the flow of processes and the final usability of the solution. I like to refer to an analyst as an artist who closes his eyes and sees the final picture ready; this time working and fully functional. Once this is done, then it is a matter of communicating with the client, the final user, to be able in one way or another to illustrate this masterpiece. This part of the process of requirements elicitation is in itself an arduous task. The analyst must finally transfer his knowledge to the developers and keep on with the various demos or iterations done to the client.
Enter ‘the client’
Just like in nature, there are various breeds in the creation, and then there are various varieties of ‘the client’. Often, the client is the one who will mislead the analyst, especially when the domain, the subject in discussion, is unknown to the analyst. In this respect the analyst must make sure that this deficiency will not be the case and while I believe that in the end it is experience which will help the analyst in achieving this task, there are many techniques in asking the right answer.
In my experience of analysing systems, I have encountered various sorts of clients. The biggest predicament is that most clients assume that what’s obvious to them is obvious for the analyst, and what now is being done by reflex, then its specifications are forgotten to be listed. Understanding the full process, without missing a single bit, is an imperative part of the requirement elicitation process. However, before understanding the problem, the analyst must apprehend the client, or rather each user in the client’s organisation. Comprehending how users think, their impression of you, their thoughts on their managers, their feelings of the current legacy system, how their desires for any future system differ from their actual needs is the most important part of the requirements gathering. While at this time the actual gathering of requirements has not yet started, the understanding of how this information will flow is essential.
Instead of employing Professor Xavier into your team, there are various questionnaires which one can either prepare and ask users to fill or, my preferred, subtly setting them up during the interview process, sometimes even during small talk. Most important, each user must be defined as how much of a ‘help’ that user might be or how much of a ‘treat’ to the project that user is. Change is always a key factor, and it is not always true that young people favour change and mature people are afraid of it – in my experience I found both, though I must say that young people do accept change more.
Infuse in ‘the domain’
Understanding your client’s business will give you better chances of succeeding in gathering the right requirements from the very first time. For example, if my line of knowledge is the manufacturing industry: the process from purchasing to manufacturing and the way a recipe is implemented on a product to go from raw materials to finished good; then most probably, my knowledge of understanding the way an airline company should work is one of guess work.
This does not mean that I cannot get the right requirements for an airline company but I would need more training in that area, thus requiring more time and as the requirements good deeper into the industry, then users will more and more assume the obvious.
The requirements
Finally, after understanding the users, possibly the client, and hopefully the domain then one can either use a formal or informal way to gather those requirements. Some studies [3] do suggest that informal ways do get the best outcome of the project – although I agree, I think that there are various other variables which do contribute to success.
My motto is that there are no exceptions,
there are simply different rules
To gather requirements there are various techniques but the core of all is asking questions, and lots of them. Often, in my meetings, I end up asking a hundred questions on the most irrelevant things – simply because I believe that the client is more susceptible to say the relevant one, and forget the irrelevant ones – most importantly when there are exceptions to a rule. My motto is that there are no exceptions, there are simply different rules. An exception will be forgotten and if remember a developer must program it, therefore a rule must be created for it. An exception in requirement elicitation is when there were requirements which were forgotten and thus must be programmed in later. However, asking too much questions may also lead to information overflow. For the analyst, probing into this information, though demanding, is much better than having to ‘invent’ it. However, often, for user, this will lead to fear that the analyst is not understanding a thing and thus making the interview process dreary. Explaining the ‘hundred thousand question’ technique to users often solves this problem.
As a person who has a visual mind, I believe that an analyst should be able to close his eyes and see the solution ready. Once the solution is ready, in my mind, it is now just a matter of making sure that this is what the client needs and that the developers do understand what is required.
Communication
Communicating to users is important since the analyst must make sure that the instructions that will be given to developers who will create the solution are those correct steps which are required to develop the end product of any requirement elicitation.
I always thought that narration with lots of visual inputs is the best solution, however not all people think alike. Presenting instruction to users to explain them what you learned and what you will propose to give them depends on the users. A questionnaire [4] could be given to them in order that the analyst can understand what type of users does he has and avoid giving lots of textual information to users who think mostly visual and lots of visual information to users who prefer it textual.
The same reasoning applies to communication with developers. There are many formal and studied ways in order to ask developers what the client needs – but most of all it is also important that the developers understand the client.
References
[1] Ian Sommerville, Pete Sawyer: Requirements Engineering – A Good Practice Guide [John Wiley and Sons, 1997]
[2] Haruhiko Kaiya, Yuutarou Shimizu, Hirotaka Yasui, Kenji Kaijiri, Mothoshi Seaki: Enhancing Domain Knowledge for Requirements Elicication with Web Mining [2010 Asia Pacific Software Engineering Conference]
[3] Colin J. Neill and Phillip A. Laplante: Requirements Engineering: The State of the Practice [IEEE Software November/December 2003 pg. 40-45]
[4] B. Soloman and R. Felder: Index of learning Styles Questionnaire [2009]. See http://www.engr.ncsu.edu/learningstyles/ilsweb.html.
Comments
Post a Comment