Career Forums

 
  Modern Analyst Forums  Business and Sy...  Requirements  Help with the structure of documenting requirements analysis
Previous Previous
 
Next Next
New Post 11/12/2013 6:38 AM
User is offline Jalz
2 posts
No Ranking


Help with the structure of documenting requirements analysis 
Modified By Chris Adams  on 11/12/2013 11:50:44 AM)

Dear all,

I’m a database developer and work within an small inhouse team which has over the course of 15 years created a school based information system. The application has stood the test of time, but as new technologies and systems are coming out, our system is starting to creake and because of the organic way it has been written has mean't that doing simple queries/tasks take far too long or are not achievable. The stakeholders want to look at either rewriting the application from scratch or buy something off the shelf that will fit into our organisation. I’ve got fairly extensive knowledge of the system as I’ve been at this organisation over 2 years and come across 90% of the users that access the software.

I’ve always wanted to get into Business Analysis, so I’ve asked the stakeholders to give me the opportunity to impress and increase my skillset perhaps for a BA role in the future. I know that developing the system in the past may influence my report, but I am going to try and remove any bias towards a solution.

My first port of call was to conduct interviews and surveys with staff to find out what is good about the current system and what simply can be done better. Most staff have been pretty quiet and not interested but I've had a couple of gems who have given me some pretty interesting ideas/concepts of what they would want as well as painful stories or problems from the current system. Although I've had quite a lot of feedback, I've split my lists into required features, desirable features, one off feature.

My question is, I now need to create a deliverable, basically a document for what the school actually so we can start looking at systems off the shelf as well as possibly using it as a document for a development team.

I'm trying to find samples of a requirements analysis document as that what I believe I am trying to create, so I can gauge the language and detail used. The sample could be anything, totally unrelated to a school system, for eg how to build an ordering system, as I'm not too bothered about the content, I'm more interested in seeing what a final deliverable report looks like, the structure, do a I break the various parts of the system, do I use bullet points/diagrams to describe the system.

I'm concerned with how much detail I should put in the report? I'm thinking of structuring it based on the user processes (i.e. parent makes enquiry to school, so we need an enquiries module which should allow the us to record parents and pupils details). should I be using usercases with these processes, it seems sensible. If I should, should I put them in the appendices and refrence them to the processes?

This maybe my first analysis, but I want to make it a good one as the document structure, etiquette in language would be the foundation of any future projects I may be involved in.

Any help/pointers would be much appreciated.

Best regards

Jalz
 

 
New Post 11/12/2013 10:13 AM
User is offline Chris Adams
323 posts
5th Level Poster






Re: Help with the structure of documenting requirements analysis 

Jalz,

First, good for you for taking the initiative and stepping up.  People often ask how they can start a career in Business Analysis with no direct experience. What you are doing is how you do it!

You are on the right track and you have two major sources of "requirements".  You have an existing system and you have system users. 

It sounds like you've done a good job of getting info from the system users.  Remember, they are going to highlight the big stuff such as what they really like or don't like.  But you need to replace this system so you still need to go through the system, system documentation, and user guides to be sure you have documented ALL of the necessary features.

One word of advice.  Requirements should be system agnostic.  When you write a requirement DO NOT assume that the system will solve the problem in a specific way.  There are often many ways that a system can fulfill a requirement.  This is the most difficult aspect of writing good requirements.  When you  begin documenting which software packages have the right features this will become very important.

Another pointer when documenting requirements is to ALWAYS include the rationale from the users perspective.  This is WHY the user needs that requirement.  As project continue requirements that once seems clear become confusing when read.  Did we me "A" or "B" when this was written.  The rationale, or the WHY, helps the reader to understand the intent of the requirement.

Finally, document who needs the requirement. Not the specific person but their role.  Roles would be things like Professor, Dean, Parent, Advisor, etc.

Most  requirements documentation and categorization are handle with simple spreadsheets.

Also realize that systems have features, and each feature can support multiple requirements.  They are not 1:1. 

There is no single template for this type of work. Every company uses what work for them.  You can also group your requirements in a lot of different ways.  But one common way is by user goals (also call use cases).  I'll keep calling them user goals/user cases describe what the system should do to provide a specific value back to the user.  You cited an example of this "Make inquiry to school".  You may want to specify the type of inquiry. I don't know your system well enough to tell you. However that single user goal can fulfilling 5, 10, or more detailed requirements.  Each use case can have actors mapped to it.  Actors can initiate or kickoff a use case. They also can provide information to the use case.

I don't want to get into to much detail on use cases.  There is a lot of information available on them. But I will say you should think about use cases in three parts.  The use case name (example: Make Inquiry to School), the use case description (a one to three sentence description of what the use case covers), the use case specification (one to many pages outlining the step by step interaction between a user of the system and the system response).  Not all literature uses references these three parts the same way so be careful to understand what they are talking about.  Also, for what you are doing I would complete avoid creating part 3, the use case specification.  These create a lot of over head and for beginner analyst are more problematic than helpful.  There are many project where I choose not to create use case specifications and I've been doing this stuff for over 15 years.

OK, that's probably enough for now ;)


Chris Adams
Core Member – ModernAnalyst.com
LinkedIn Profile
 
New Post 11/13/2013 8:51 AM
User is offline dldelancey
61 posts
8th Level Poster


Re: Help with the structure of documenting requirements analysis 

Lots of good information in Chris' reply.  I'll add that you want to tailor your deliverables to the audience.  If you're creating something that allows the business stakeholders to determine if you have understood their needs, then your deliverable should be in a format they want to review and using language they understand.  If you're creating something that allows the technical team to build the solution, that's a different animal.  You CAN achieve both in one deliverable, but it is challenging.  If you keep in mind that the two groups likely don't speak the same language, you'll be much better off.

 
New Post 11/13/2013 1:44 PM
User is offline Jalz
2 posts
No Ranking


Re: Help with the structure of documenting requirements analysis 

Hi Chris

Thank you for the reply, you've given me a lot to chew on, lots of valuable information and I've started investigating into user cases as I think it would be quite useful the more I read about it. Its quite an interesting technique, hopefully I can get the grasp of it, actors dependencies associations etc.

I'll keep reading up on BA techniques, its an exciting new world which has really got me thinking about the little details.

 
New Post 11/13/2013 4:52 PM
User is offline Chris Adams
323 posts
5th Level Poster






Re: Help with the structure of documenting requirements analysis 
Modified By Chris Adams  on 11/13/2013 6:52:46 PM)

Use Cases place a focues on the value the system delivers to its users.  That's one of it's big advantages.  But remember, don't get to caught up in them.  I would look into the Use Case Model and how to create one.  For each Oval on your model you can have a one to three line description.  Beyond that and you will probably get yourself in too deep and not extract real value.


Chris Adams
Core Member – ModernAnalyst.com
LinkedIn Profile
 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Help with the structure of documenting requirements analysis

 






 

Copyright 2006-2024 by Modern Analyst Media LLC