Monday, December 11, 2017

What and How of Requirement Gathering - Part 2

In continuation to my previous post, I’ll add some more techniques which are popularly used for information gathering.

Interviewing: While on one hand shadowing provides an effective means to discover what is currently being done in the business, but on the other hand it does not provide all the necessary information. Another flaw of shadowing would be, it is not suitable for getting information about long-term activities that extent weeks or months along with the processes that requires very less or no human intervention. Hence, we can look for other techniques like interviewing.

Interviewing someone is the one-on-one meeting between project team and the user.
Here quality of information totally depends upon interviewee and the interviewer. The interviewer can ask a wide range of questions as compared to shadowing mechanism. These questions can be from basic information to difficulties to limitations of the system. During the interview process, the interviewee can give some ideas to improvise the solution, but one should avoid assuming that those ideas are the correct solution.

The success of this technique totally depends on how the questions are structured or framed? The interviewer should be in a position to get more and more questions out of the answers given by the interviewee. One should always avoid asking misleading questions.
Few of the standard questions that can be asked during this process can be:
  • Is there any documentation available to help you in performing your job?
  • Is there any third party, that affect your work – i.e. support specialists, external suppliers/system, etc.?
  • Does any business policy hinder you in performing your job?
  • Do you need any assistance or help when you work remotely? If yes, then what?

Surveys: Surveys are the other means of gathering information. It consists of a collection of questions. A very good example of surveys is the customer feedback form.
One of the best parts of surveys is that, they keep the identity of the user hidden as they can be given anonymously, which in turn promoted confidentiality.  Such kind of information gathering technique is useful when one is more concerned about the responses rather than which individual has responded.
The most difficult part of surveys is its preparation. Everyone cannot come up with surveys as is requires a trained professional for choosing questions and then analyzing the responses.
Note: Surveys can be affected by user attitude or mood :(
Few are the common examples of information that can be collected via surveys:
  • Organizational structure
  • Policies
  • Training material and instructor feedback
  • Customer satisfaction surveys, etc.
Hope you got an idea about interviewing and surveying technique and when to use what. In my next blog post, I’ll continue to write about few more techniques.
Till then keep reading.

Saturday, December 9, 2017

What and How of Requirement Gathering - Part 1

This time rather than writing on some technology or solution, I thought to write on one of the important phases of SDLC which is nothing but requirement gathering. To be more specific, this article will be more about collecting information about business requirement. What are the various sources to get and understand most of the portions of any business requirement.

It’ very important to understand that, information can be gathered from many standpoints. It can be from Business front, Application front, Operations front, Technology front, and may be many more. So, while gathering information, one should have a clear vision on what kind of information they are looking for. Let’s have a look at few of the well-known categories:

  • Business – Goal of business, Service offerings, Products, Financial Structure, etc.
  • Application – Productivity tools, interaction with business application system, Code Modules, etc.
  • Operations – Identify the information’s origin, information’s consumption, information’s ownership, Data warehousing, Data models, Data Management policies, etc.
  • Technology-Technical Services, i.e. Development Environment, Topologies, Network Services, Security, DBMS, Technical Specifications, Hardware, Software etc.

The next biggest question would be how to gather all this information?
If you will search on the internet about how to gather information, you will get lot many ways. But most of these tactics, more or less fall into 1 of the below categories:

Shadowing: In this technique one will observe a user performing the tasks in an actual world environment and ask the user any questions related to the task. It is basically like following the user as he or she performs daily tasks. In other words, more the questions, more the information.
Note: This technique is effective only for frequently performed activities or tasks because if the task is performed occasionally, then it would be difficult to shadow someone.
Some common questions which can be asked during shadowing can be:-
  • What decisions do users make when starting or completing a task?
  • What modifications must be made over time to make it easier to complete the task?
  • Which related tasks may affect the design of the solution?
  • Are there any performance criteria?
  • How many people does a user interact during a given task?
  • Are there any variations in the steps to complete the task?
  • How often does system or management interfere with their job?
  • What do users like/dislike about the system?
  • Characteristics and preferences of user.
  • Concepts and terminology used by users?
  • What trainings do users need?
  • How can training and support costs can be reduced?
  • Have users been through the training or they are self-taught?
  • What information about the user is not documented?
In essence, one has to observe and question both the management and the users. If there are any external stakeholders involved with the task then they should also be part of this observation.
Hope you got an overview of shadowing. There are a few more techniques, which can be considered in order to get the required information for starting any project. But being a completely theoretical write-up, I would like to end this blog here itself and will write about more techniques in my next blog.
Till then keep reading.

Friday, December 1, 2017

Generating XML Root Node having colon - via Serialization

Recently I got a requirement to generate an XML on the fly with some defined schema. I know this requirement looks very simple in first sight, but actually it was not.

The XML which was to be generated was having a very specific format as it was supposed to be the input for some 3rd party tool. So, it means, it should be fully compliant with the prescribed XML node structure. Just have a look at the below schema:

<sl:RandomWindow xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sl="http://www.ShwetaBlogs.com/Window" xsi:schemaLocation="http://www.ShwetaBlogs.com/Window wwRandomWindow.xsd">
  <Title>First Window</Title>
  <Border>Single</Border>
</sl:RandomWindow>

Below are the classes I created for serialization purpose:













By using the XmlElement and XmlAttribute classes I was able to generate most of the required parts of the XML as shown below:







But the only thing which didn’t come up correctly was the root node which is expected to be in the form <sl:RandomWindow>.

So, in order to achieve root node with prefix and colon, I updated the code to:

[XmlRoot("sl:RandomWindow")]
    public class RandomWindow {…}

But alas! It gave me some strange results. It converted the prefix to hexadecimal as shown below:







Then I thought, instead of providing concrete prefix, let’s add namespace itself as shown below:
[XmlRoot("RandomWindow", Namespace = "http://www.ShwetaBlogs.com/Window")]
     public class RandomWindow { ... }

And my result was:







Which was bit closer to what I need, but not the exact one. Now the issue remaining was the extra prefix in front of each element :(.

In order to resolve this issue, I tried various options provided over various blogs, but no luck.

But after spending hours, I was able to crack it by hit and try. To hide namespaces at element node level, I provided the namespace value as empty as shown below:















And that did the trick for me. Finally, I was able to achieve the required format.







Although this issue was pretending to be very small, it ate up my so much time. So, thought to share it here. Hope it would be helpful for you too.

Happy troubleshooting !!!