Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  How to keep original business requirements updated with enhancements
Previous Previous
 
Next Next
New Post 10/15/2018 4:07 PM
User is offline Analyst Al
1 posts
No Ranking


How to keep original business requirements updated with enhancements 

First post so want to say a bug hi to the whole community.

What are the best practices for keeping original business requirements updated once enhancements are tacked on to the product?

Do you go back to the originals and update the wireframes, fields etc? What other methods are best practices?

 

Thanks

 
New Post 10/17/2018 1:10 PM
User is offline Chris Adams
311 posts
5th Level Poster






Re: How to keep original business requirements updated with enhancements 

 

Welcome!

The level to which requirements may be kept up-to-date sometimes varies from company to company based on methodology.  For instance, some agile teams don't believe in keeping user stories once the features are implemented. They say, "the code is the only documentation needed". I disagree with this as I think most analysts and IT professionals do. I believe it's a misunderstanding of the intent of Agile.

First, let's be clear that requirements aren't just text based.  Anything that documents WHAT the system should do is part of your requirements documentation.  Depending on methodology used, this might include "the system shall..." type statements, data models, wireframes, user stories, process flows, or other models.  I prefer to use minimal documentation focusing on what makes sense for a particular situation, but always keep the documentation up-to-date.  

You specifically mentioned wireframes so I'd like to speak to those and other screen mockups and prototypes since I don't believe these should be considered true requirements documentation.  Wireframes and mockups should be used with care as they are an inexact way to communicate requirements. They can be good at communicating visual layouts and concepts. They are helpful for generating stakeholder feedback as part of the requirements elicitation process, but the requirements should be documented in other ways so that the team can be confident that requirements have been documented accurately and unambiguously. Wireframes and mockups can introduce ambiguity as they often unknowingly imply design decisions.  Design decisions are very different from requirements.  They go beyond WHAT they system should do and define HOW it will be done. For instance, if I place a button on a mockup am I telling the development team that a function must be triggered by a button? Is there another way that this function could be triggered? What about the placement of information on a screen? Was it fully thought through? Or, as is often the case, were quick assumptions made during the wireframing process?  What in the mockup is a true requirement versus an unconscious decision or assumption?

Beyond mockups and prototypes, most everything else should be maintained and updated when changes come down the pipeline.  The majority of the work was done when creating it the first time around.  Updating models or test cases associated with user stories shouldn't take much time. And it's this process that will often uncover requirement conflicts before coding of new features or changes begin.



Chris Adams
Core Member – ModernAnalyst.com
LinkedIn Profile
 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  How to keep original business requirements updated with enhancements

Community Blog - Latest Posts

Trividh Patel, CBAP
Trividh Patel, CBAP
At first, I wanted to tell people how they should go about getting their IIBA certification. But then I thought the best way to do this is by actually telling “how did I achieve my own CBAP?” So, friends here is my story. I started working as Business Analyst in 2002. I have used multiple elicitation techniques (such as interviewing,...
1 Responses
Ekaterina Barabash
Ekaterina Barabash
I address my thoughts to those who are in IT management for whom the terms such as quality of project implementation development and profitability indicators of the company are important.  And it is also addressed to business analysts whose daily routine is the process of communication with Customer. A little about myself first. The last 8...
0 Responses
Dan Tasker
Dan Tasker
I have long been a believer in the saying “Context is everything.” As a business analyst dealing with business users, understanding the context of the topic of discussion is essential. In thinking about what constitutes quality requirements it occurred to me that there are a number of additional contexts that play a role. Examples inclu...
1 Responses




Latest Articles

Requirement Elicitation: Stories Are Not Requirements
Mar 17, 2019
0 Comments
  One of the three activities encompassed under Requirements Analysis is the process of ‘ Requirements elicitation’. IIBA’s de...
Featured Digital Library Resources 
Copyright 2006-2019 by Modern Analyst Media LLC