Article Menu

Tuesday, 23 August 2011 09:23

Do it Yourself Guide for Building Templates

Written by 
Rate this item
(0 votes)

Aug23rd_FEATUREWhen the requirements document templates that you have to use within an organization do not fit the situation, you should consider making a new template. There will be organizational procedures that you will need to follow but it is possible to request new templates for your project needs if you believe it provides a higher-quality deliverable.  Senior analysts can recognize such opportunities when they arise and have the skill set to create new formatting for requirements deliverables.  Less experienced analysts rarely think of building new templates but what you need to remember is that someone built that template from scratch so it’s not impossible or even a real obstacle. Rather, it could be the next building block to increasing your skills. 

When standard procedures and processes, templates or job aides do not give you what you need to be successful, managers expect business analysts to utilize their expertise and create what they need for projects.  Three common mistakes that business analysts can easily avoid are:

1) Refraining from using excuses such as “the pre-set templates are all I have to work with.”

2) Assuming you are not empowered to improve processes or expand the tools of your trade.

3) Listening to more experienced peers insist that their template fits every business situation.

     You need to first agree that there is not a one-size-fits-all requirements template document.  If you don’t believe this is the case then compare a requirements document designed for product development to a requirements document for a services organization responsible for product implementations.  What’s different about these two documents?  The differences between requirements documents within each organization are found in the intended audience, the document’s purpose and the overall tone or message.

     You might have a difficult time finding a requirements document for product development today since many organizations are changing to AGILE methods. The requirements document for product development is an output of a waterfall methodology for software development in which the market and business or detailed requirements were written out mainly for the purposes of developing the software.  Sometimes it’s called a business requirements document (BRD) and can be split with another requirements document called a software requirements document (SRD). Focusing on just the SRD, the audience is internal resources, mainly developers and testers. The intent is to provide the detailed system requirements (and sometimes non-functional requirements) for verification testing.  These requirements tend to be more feature- or function-driven with details about processing. The message or the purpose of the document is to provide direction for development organization in terms of scope, assumptions, constraints and detailed functional or non-functional requirements.

     With software implementations, the requirements document has a completely different purpose. First, the audience is your client. The client reviewers of this document can perform various roles within the client organization, including CEO, executive leadership, Director, Manager, subject matter expert (SME), and project team member.  The intent of the requirements document is to provide the recommended implementation approach for how the product can be implemented to meet the needs of the organization.  The message or purpose should be to easily and succinctly give executive management a clear picture of how the product matches up with the organizational goals.  Therefore, it should include an executive summary.  If there are unfulfilled requirements, they need to be clearly spelled out so executives understand the impact to the business and whether or not there are viable workarounds.   If there are decisions to be made prior to proceeding, it should be there and if there is additional work requiring new contracting or additional expenses, it must be noted in an executive summary.  As a manager of BAs, I insist that a requirements document should not exceed 25 pages in length and should include the detailed requirements in an attachment. All the detailed business requirements and specifics can be attached as references or included in appendixes at the end of the document.

     If the above scenarios for product and service requirement documents do not describe your situation, the direction that you have been given by your management team, or resemble the document structure that you use within your organization, don’t be surprised.  That is the whole point, as there are so many other variations for requirements documents.  The question is:  Which document is right for your situation?  You can make a determination regarding what you think would improve your templates once you begin to comprehend the reason and purpose behind the document template you’re currently using.

If you are thinking about creating your own template, ask yourself these few basic questions.  If you can answer “yes” to all three then you can successfully make a case to build another document template.

  1. Do I understand the audience, document purpose and message in the current templates?
  2. Have I formulated the message and done the analysis necessary to write a good requirements document?
  3. Do I have a unique need that is not fulfilled by the current template?

     If you do NOT answer “yes” to the above questions then your business case will not succeed. It will highlight flaws in your own analysis skills and that is something most people prefer not to bring to the attention of their manager.  Bringing a case for a new template  to management and not being properly prepared could bring to light root causes for why you are struggling to write requirements documents that have nothing to do with the template itself.  Common reasons that analysts struggle when using templates are:

  • Not realizing what is supposed to be documented.
  • Not having the analysis complete.
  • Weakness in underlying business writing skills that cause difficulties using a template, including problems with how to express opinions, persuade a reader, influence a decision, etc.
  • Lack of advanced Microsoft Word features knowledge such as inserting pictures or objects, inserting hyperlinks, modifying pictures, using and including styles, advanced page break or header/footer notation and section breaks.

If you did answer “yes” to the three questions above then you have to ask yourself if you want to improve the process within your organization.  You can do so by following a few simple rules: 

  • Talk to your manager about your intentions and he/she can connect you with the right resource within your organization. 
  • Recognize that someone is already in charge of the processes.  Check in with that individual and explain your situation. 
  • Partner with a few peers in order to get your idea realized and your template streamlined by building your business case and explaining your current need.

Do not forget how important including your peers can be to succeeding in new template development.   They can give you feedback, improve your template, and support its usefulness and need within the department.  If they are aware and were part of its creation, they will be less likely to resist using the document once it’s part of standard operation procedure.

Working towards improving templates and processes by building new tools for team use is a great way to show initiative and creativity.  It shows a commitment to quality and an interest in improving processes within your organization. Your leadership skills can be demonstrated by taking the time to work through an idea and navigating organizational processes and politics to see your ideas turned into realized solutions.
 
Don't forget to leave your comments below.

Maryanne Miller, CBAP, Business Services Manager for MEDecision, Inc., has over 15 years of business and technical experience in the corporate world of health care IT services. As a professional consultant providing business and technology leadership, her areas of experience include business process improvement, business analysis, and health care IT.  

Read 5172 times Last modified on Monday, 02 April 2012 16:30
Published in Articles
Maryanne Miller

Latest from Maryanne Miller

More in this category: « Business Analyst "Real Jobs" -- Define the Problem Three Baby Steps Toward Agile Requirements Management »

Comments  

 
0 # Colin 2011-08-23 13:55
You say "the intent of the requirements document is to provide the recommended implementation approach for how the product can be implemented to meet the needs of the organization". I have to disagree with this statement. IMH O the Requirements document should define what the requirements of the product or service are, not how they should be implemented. T he document you are describing sounds more like a Solution Outline document, which describes one or more possible Solutions that meet the requirements, (if more than one then it defines the pros and cons of each, with a recommendation) .
Reply | Reply with quote | Quote
 
 
0 # Maryanne miller 2011-08-23 14:09
Typically i would tend to agree w/ you but again my point here is that is dependent on the needs of your organization for a requirements doc. Our project have separate SOWs between Requirements and System Implementations . This is so Requirements can be analyzed and solution approach is wrapped into our requirement doc's so that the client understand the next phase for implementation and signs off on any add'l customizations, workarounds and changes to process necessary for streamlined implementation. Every organization has ideas about what a Requirements doc is- it's nit the same everywhere nor should it be.
Reply | Reply with quote | Quote
 
 
0 # Kupe 2011-08-23 21:10
I know where you are going here and agree with the overall premise. Document what is necessary for the project. Don't just fill out a template becuae it is there and don't leave things out because the template does not have a spot for it. What I struggle with, is you state a requirements doc should not exceed 25 pages and all detail should be in an appendix. Isn't that a template constraint? Why 25, not 15? I bring this up because I have been in situations where people just complain there are too many pages. So, is just reducing the number of pages the answer? If it takes 400 pages use 400 pages. What the problem usually ends up being is how the requirements are communicated. if you plop down a 400 page doc and say read this, people will revolt. My point is use however many pages you need, just make sure you communicate the requirements based on the needs of the consumer.
Reply | Reply with quote | Quote
 
 
0 # Maryanne Miller 2011-08-24 01:22
My statement recommending that a requirements document should not exceed 25 pgs is a guideline. Actually, I adopted that guideline from a presenter whom suggested it but I can’t remember who it was to give him the proper credit. I was in the middle of rewriting methodology for our department and put that into practice and it seems to be a good guideline that works for us. A document can be smaller at times – we do that all the time for small maintenance work. What I find is that many BAs inherently translate their many months of requirements activity into large cumbersome documents so I do believe you hit the nail on the head – think about the communication of the material. Months of elicitation and analysis does not necessarily need to transcribe into 50 pg requirements doc – most reviewers want a more succinct, clear and easy to read message. What I didn’t get into much detail on is how we’ve also went from primarily a text based document to a model and workflow doc with text as secondary support. There’s always room to question the template, the process and the tools . Thank you for your comment – mode of communication is key.
Reply | Reply with quote | Quote
 
 
0 # Kupe 2011-08-25 00:39
Pictures with necessary text is always better! I don't like to say always and never, but don't see when text alone is a better option if you can paint a picture.
Reply | Reply with quote | Quote
 
 
0 # Asif Jehangir 2011-09-05 16:54
I have adopted a new idea for each group of stakeholders or SME from different dept. I create a separate requirement document for each group for any single business need. but the main signing document that has the summary of Business Needs and Business requirments is the standard one for all. because you cannot directly imposed you state of the art requirement document ,that only you can underdstand ,for first few projects you should be designing custom documents and when you think that now all stakeholders are statisfied wiht your work and trust you a lot ,then try to standardize or use holistic approach . but in some cases you still will be using custom templates. "bea cuse everything is permanent except change"
Reply | Reply with quote | Quote
 
 
0 # Leslie 2011-09-13 06:47
"As a manager of BAs, I insist that a requirements document should not exceed 25 pages in length and should include the detailed requirements in an attachment." W hy .. what is the purpose? If it takes more than 25 pages to document my analysis diagrams, am I supposed to use a smaller font or larger paper? I can guess at the reasoning behind this guideline, but unless explained it makes no sense. The document should be as large as it needs to be in order to get its message across in a readable manner, and no larger. Basic Guidelines To Writing Any Technical Document: Who needs this? - What is the role that asked for this information. Wh at is it that they will do with the information in the document? - Only document what they need documented. How do they need the information presented? - Make sure the information in the document is in a format that the persons needing the information will understand. Un less the information needed is identical and required in a similar format, try to avoid writing a document for more than one audience role. The larger the audience that the document is intended for (I've often seen a single Requirements Document written for every role on the project), the less likely necessary roles are going to adequately review the document - therefore the less value the document brings to the organization. Target your documents - don't use a 'one size fits all' approach.
Reply | Reply with quote | Quote
 
 
0 # Karl Wiegers 2011-09-25 08:21
I agree with both of Kupe's comments. First, I see no reason to limit a requirements document to any arbitrary size. There are big projects and there are small projects. Simply putting the details someplace else, like an appendix, doesn't change the quantity of material. A requirements specification should be however long and detailed it needs to be to allow design, development, and testing to proceed at an acceptable level of risk, the risk being the need to do unanticipated and excessive rework. In many cases you need to create more than one kind of requirements documentation to meet the needs of diverse audiences: a vision and scope document for business requirements, for example, and a software requirements specification for functional and nonfunctional requirements. Instead of limiting us to thinking about documents, I prefer to think about "containers" to store whatever requirements information is necessary in appropriate and effective forms. I also agree with Kupe's suggestion about using pictures along with text. A skillful BA will be able to judge the most appropriate techniques for effectively communicating the necessary information to the intended audience(s) at an appropriate level of detail. Alternatives to straight text include analysis models, photographs, video and audio recordings, tables, lists, decision tables and trees, and so forth. I like to start with a rich template for a particular deliverable I need to create and then apply the principle "shrink to fit." The rich template reminds me to think about many types of information I should contemplate addressing in my deliverable. If I don't need a particular type of information, fine, but that is at least a conscious decision, rather than being a default decision because it didn't occur to me. This approach makes me less likely to overlook something important.
Reply | Reply with quote | Quote
 
 
0 # Maryanne 2011-10-04 07:25
Thanks for all your comments. I agree there is a balance on how long a document should be but again I often edit materials down to be succinct and clear. A lengthy doc isn't necessarily a quality document. I spend many hours minimizing messages to 'get to the point'. What I need to stress about my opinion on our process is that our req/solution doc right now leads to the new SOW for the product Implementations (not product development). Seeing the reader is often the executive leadership - I spend time trying to re-train business writing to communicate to a different level of stakeholder than most BA's are familiar. That's why we changed to modeling and use cases at the business level and are looking to get away fully with detailed Requirements.
Reply | Reply with quote | Quote
 
 
0 # C Cheung 2011-10-06 05:23
The problems itemized about Word in this article are exactly the problems I am encountering. Can anyone recommend some alternative tools for writing requirement documents?
Reply | Reply with quote | Quote
 

Add comment

back to top