Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  reverse engineering for requirements
Previous Previous
 
Next Next
New Post 8/11/2008 4:33 AM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




reverse engineering for requirements 
Modified By Adrian M.  on 8/13/2008 2:43:28 PM)

A discussion at the Agile Modelling Group put this picture into my head.

The original question was about how to go an document requirements for an existing system. My initial response was why would you want to reverse engineer a system back to requirements?

It makes sense to me to get a full picture of what a system can do - and so document features, but I can't get why you would take things back to requirements.

After all, requirements are a statement around a particular problem or opportunity, not a design specification.

The diagram below came to me care of a comment made by Jon Kern.

 

Jon notes that not all formally accepted requirements make it in to the final release. Sometimes they are too hard, sometimes you run out of time and money before you get there.

Additionally extra non-formal requirements often make their way into the final release. Non-formal requirements arise from a number of places including uncontrolled requirements changes, requirements elaboration and developers realizing that a neat feature is just 30 minutes of code away.

So at the end of the day, a system doesn't match any particular set of requirements anyway.

Now, there is a case for re-using requirements. After all, if you have a set of standard requirements for say, logging into a system, why not re-use them. It saves time and builds consistency.  But requirements re-use isn't the same thing as reverse engineering a system to establish requirements.

I ask again; what value can there be in this? Any suggestions out there?

 

Orinally posted to www.betterprojects.net

 
New Post 8/11/2008 1:53 PM
User is offline James-STL
10 posts
10th Level Poster


Re: reverse engineering for requirements 

I'm perplexed as well Craig. Perhaps, (and i'm just throwing this out there), for traceability? Perhaps the requirements were not documented or unavailable. Perhaps there have been modifications that are not supported in the documents.

 

That's my 2 cents. Loooking forward to other comments and perspectives.

 
New Post 8/13/2008 12:56 PM
User is offline Adrian M.
733 posts
3rd Level Poster




Re: reverse engineering for requirements 

Hi Craig,

There are a number of instances when value is achieved from reverse engineering:

  • Convert a legacy system to a new platform therefore you need to know what the existing system does.  I realize that many folks would say that in this case we should go back to the users and elicit requirements rather than reverse engineering the system.  The reality is that if the current system works just fine it is much more efficient to get a baseline list of features from the existing system as compared to starting a formal requirements process.  Gathering requirements from stakeholders is not cheap but very expensive due to the cost of people's time.
  • The system will need to be maintained for much longer therefore it is a good idea to gradually reverse engineer and document the existing behavior of the system so that when future changes come the next analyst does not have to re-engineer again.  Here the result of reverse engineering would probably be just functional specifications.

- Adrian


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 8/13/2008 11:19 PM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: reverse engineering for requirements 

Andrew offers an opinion in the comments to tmhis post at BetterProjects.  He suggests it's in the name.

To me and him a requirement is an unfulfilled need/want.  Once a system has a feature the reqirements is addressed.  Now you have a feature in a system.  And a feature may be picked up for more uses that the original requirements, so my view reminas - reverseengineering requirements seems like a wrong and overly complex approach when all you need is to understand the features.

Maybe we use the term differently?

 
New Post 8/14/2008 5:31 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: reverse engineering for requirements 

Hi:

Why the need to reverse engineer a system back to its requirements?

Core essential requirements are largely static.   Example:  A retail store calculates sales tax.   The store has always had this as an essential - unchanging - requirement, and it probably always will.

 Now the mechanism used to accomplish this fucntional requirement can be anything from a person with pencil and paper, a calculator, or a computer.   The mechanism may change, but the essential requirement (to calculate sales tax) remains.

What we need when we develope a new system is a comprehensive understanding of all the largely unchanging essential requirements.   In the past, some of these were implemented in older systems.   Some were not. (maybe, for example, they were done manually ).  We need them all.

Granted when we reverse engineer the existing system for the essential, we have to pold through alot of non-essential (i.e., implementation specific) requirements.  And we really don't need the non-essential requirements from the old system to develop a new system.  But there really is no way to avoid analyzing them - the essential is typically buried deep within the non-essential.

So, we need to reverse engineer the old system to get those essenital requirements that are currently accomplished by the system.

Tony

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  reverse engineering for requirements

Community Blog - Latest Posts

Gen1us2k
Gen1us2k
Most of the IT projects imply constant cooperation between the team members and customers. Although it might be often overlooked, the role and the importance of the client within the project is very crucial. Thus, it is in your interest to build a strong relationship based on trust. However, gaining trust on a single occasion is not a dealmaker &md...
0 Responses
emorphistechno
emorphistechno
Introduction In today's world, most enterprises work aggressively to achieve a higher level of business growth, which is made possible by leveraging one of the best automation technologies. One such technology is Robotic Process Automation (RPA) that plays a vital role in streamlining the customer experience in the most profitable manner.&nb...
0 Responses
Nick Stowers
Nick Stowers
Introduction   When I was introduced to scrum, the burndown chart was a tool that was highly emphasised however I feel the purpose has changed from it being a tool to predict (to a certain level) timescales for delivery to a tool that measures a team’s productivity…..in other words, the focus is on the number of points clear...
0 Responses






Copyright 2006-2020 by Modern Analyst Media LLC