When you start a new job, even if you are an expert with lots of experience in the domain in which you new employer work, you have to learn.  Sometimes the learning curve is small, sometimes long – in any case there is always a learning curve.  In a healthy environment, there is bi-directional learning process.  You will learn your new job, but you will also teach your experiences to your co-workers and employer.  Everyone has something to give back.  The same aspect can be also considered for an analyst who’s task is to gather requirements from a new client.  The learning experience is also two-way, since users do also learn, or will learn, from the analyst. [1]

In order to explain the introduction of this blog better, let’s discuss a scenario:

Dexter, our fictitious analyst, is assigned to analyse the stock control requirements of Store-n-Sell Limited, our fictitious client.  When Dexter meets Tony, the store manager for Store-n-Sell, Tony explains the process that happens in the store.  Tony may be a ‘good tutor’ and knowing the process well he can help Dexter to understand, or rather to ‘learn’ the requirements.  Dexter on the other hand is also a ‘good tutor’ and during the elicitation process, as an expert in stores management and stock controls, he teaches, actually suggests, Tony improvements that can be done to optimise the process [*], discusses his opinions on how the software can work to help Tony who is absorbing all information from Dexter.

Requirements Elicitation is thus also a two way learning process.  So, knowing how one learns is a plus for the system analyst.  In my previous blog post, I listed that the apprehending the user is a vital aspect of the elicitation process.  Often the analyst must be capable of understanding how the user is feeling about this whole elicitation process and also about the user’s task itself.  Just like the analyst must understand the user’s feelings, the analyst must also understand how the user learn and, maybe more important, how the analyst oneself learns.  Understanding how you learn will put you on the right track to ask for things in the right way.

Know your users and yourself

For the analyst using the Felder-Silverman Learning Style Models (LSM) [2] the idea is that a questionnaire is given to the users and the result will help the analyst to understand how the users prefer to learn.  In this way if users prefer more visual material to learn, the analyst will not present a document full of text.  The Felder-Silverman LSM divides the ‘student’ into 4 different aspect:

Active vs Reflective Learners: Try vs Think

Active learners will learn more quickly if they do something.  So it is not useful to do explanations and demos if they do not do hands-on session.  On the other hand reflective learners absorb knowledge and then think about it, and memory-train themselves.

Sensing vs Intuitive Learners: Fact vs My Way

A sensing learner likes to solve problems and learn facts using well established methods.  So if your user is a sensing learning it is useful to present the solution in the form of a ‘formula’.  On the other hand intuitive learners will need to ‘invent’ their method by discovering all the possibilities and relationships.

Visual vs Verbal: Pictures vs Text

A visual learner learns best by looking at pictures, diagrams, demos, videos, flow charts and anything that is visible – these remains in memory and information is loaded and associated more easily.  A verbal learner will be better off when text is written or spoken rather than images presented to them.  Obviously this, as a matter of fact any other section, this does not mean that a learner will learn most using 100% their way – they need both ways but focused on their preferred method.  Most probably during lectures a visual learner will design images while a verbal learner will write notes in the form of text.

Sequential vs Global: One, two, three vs The Big Picture

A sequential learner will learn one step after another.  This means that the process must be defined in steps, one leading to another and finally concluding – this way the ‘student’ can help create an understanding of the problem in sequential but simpler steps.  A global learner does not care the sequence.  This type of ‘student’ will want to gather lots of information, often without any apparent normal logic or usefulness between it, until at once point the picture becomes clear and the problem is understood.  Usually a global learner will skim through a book in no apparent logical way or sequence, maybe never read it all, and still get it.

The Questionnaire

The questionnaire discussed can be found at http://www.engr.ncsu.edu/learningstyles/ilsweb.html.  When users fill it they are presented with results which should help the analyst acquire a guidelines of the diversity of users’ preferences help them present the elicitation interviews and also in presenting any documentation on the findings and proposed solutions according to those needs [3].  It will also help the analyst to understand oneself and ask users questions which will be answered in the way the analyst understands most.

@evancamilleri

_______

[*] I believe that a good analyst is also a consultant in helping to improve the business – but that’s a discussion for another blog post.

References

[1] 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].

[2] B. Soloman and R. Felder: Index of learning Styles Questionnaire [2009].  http://www.engr.ncsu.edu/learningstyles/ilsweb.html.

[3] R. Felder and J. Spurlin: Applications, Reliability and Validity of the Index of Learning Styles. [2005 International Journal of Engineering Education]

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 for 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.

Of EvanCamilleri.com

I will be taking a journey into Requirements Elicitation.  My goal is to consolidate what I learned during my studies and most important during my experiences.  In the coming weeks, months and hopefully years I will be studying various aspects of requirements elicitation with the objective to become a better analyst, understand better my clients, and in the process meeting you readers along the way.

Follow me on Twitter @evancamilleri.

_______

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.

Just a small note!  Yesterday, the world lost a visionary writer who predicted our lifestyle in the future.

As my favourite author, I never had to pleasure to meet him but for sure I met him in his stories.  Benjamin Franklin who once said, “To be remembered, either write something worth reading or do something worth writing about”.

Arthur C Clarke will be with us for a long long time because he did both!

Routines

declare @OldOwner varchar(100)
set @OldOwner = 'oldOwner'

declare @NewOwner varchar(100)
set @NewOwner = 'dbo'

select 'sp_changeobjectowner ''[' + routine_schema + '].[' + routine_name + ']'', ''' + @NewOwner + '''go'
from information_schema.routines where routine_schema = @OldOwner

Tables

(take care that Triggers are seperate objects)

declare @OldOwner varchar(100)
set @OldOwner = 'oldOwner'

declare @NewOwner varchar(100)
set @NewOwner = 'dbo'

select 'sp_changeobjectowner ''[' + table_schema + '].[' + table_name + ']'', ''' + @NewOwner + '''go'
from information_schema.tables where Table_schema = @OldOwner

Single Object

EXEC sp_changeobjectowner 'oldOwner.ObjectName', 'dbo'

Remember: from Query Analyser CTRL-T to do them in text output (not data grid output)

BACKUP LOG database_name WITH TRUNCATE_ONLY
GO
DBCC SHRINKDATABASE( database_name )
GO

Unfortunately Windows event log lists and error that the log has been ‘shrinked’.  Obviously you do not need to worry (except if you needed those logs!) since you know that you did that action and for what!