Home > Archive > Software Engineering > November 2006 > Identifying requirements from the product
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Identifying requirements from the product
|
|
| v4vijayakumar 2006-11-22, 4:00 am |
| You see a software and wonder what requirements would have made someone
to develop such a software. How we can identify the requirements from
the working software product? What you call for this process of
identifying requirements from the working software product? Reverse
Engineering?
| |
| H. S. Lahman 2006-11-22, 9:59 pm |
| Responding to V4vijayakumar...
> You see a software and wonder what requirements would have made someone
> to develop such a software. How we can identify the requirements from
> the working software product? What you call for this process of
> identifying requirements from the working software product? Reverse
> Engineering?
There is no reliable way to do that, other than through external
documentation. That's because the software, whether as a high level
design or a 3GL source, is always a solution model. Many decisions have
been made by the developer of the model and the notations do not provide
a mechanism for explaining Why the developer made those decisions. IOW,
there is no way to tell if the developer did something because
functional requirements explicitly required it, because it was a design
decision in addressing nonfunctional requirements based on the
particular computing environment (e.g., technologies, available
libraries, etc.), or it was simply an arbitrary choice (e.g., based on
personal style).
Reverse engineering is the tool of last resort in trying to infer
requirements in a system without external documentation of the
requirements or the software itself. There are a lot of ambiguities in
working back from 3GL (or, worse, Assembly) code for the reasons above.
Also the level of abstraction is far too detailed so one has a classic
forest vs. trees problem. The reverse engineering tool just provides
one with a view of the lowest level of design, not the customer's view.
(In fact, reverse engineering tool vendors must make specific
assumptions about the intent just to provide a more abstract
representation and those assumptions are not always even correct.)
Perhaps the most insidious problem with reverse engineering is that it
strongly encourages repeating the mistakes of the past. If an
application is badly structured, reverse engineering just yields a bad
model of what the application does. When one does not know what the
requirements actually are, that bad structure can easily be interpreted
as requirements.
The most common reason to do reverse engineering to determine
requirements is because one needs to replace an obsolete or
unmaintainable systems that is not properly documented. In that
situation I would go to the customer, elicit the requirements directly,
and build the replacement as if it were new software. In such
situations reverse engineering does not save any time and it can
actually lead to a product that has many of the same problems as the
original software.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
| v4vijayakumar 2006-11-23, 4:00 am |
|
H. S. Lahman wrote:
> Responding to V4vijayakumar...
>
>
> There is no reliable way to do that, other than through external
> documentation. That's because the software, whether as a high level
> design or a 3GL source, is always a solution model. Many decisions have
> been made by the developer of the model and the notations do not provide
> a mechanism for explaining Why the developer made those decisions. IOW,
> there is no way to tell if the developer did something because
> functional requirements explicitly required it, because it was a design
> decision in addressing nonfunctional requirements based on the
> particular computing environment (e.g., technologies, available
> libraries, etc.), or it was simply an arbitrary choice (e.g., based on
> personal style).
>
> Reverse engineering is the tool of last resort in trying to infer
> requirements in a system without external documentation of the
> requirements or the software itself. There are a lot of ambiguities in
> working back from 3GL (or, worse, Assembly) code for the reasons above.
> Also the level of abstraction is far too detailed so one has a classic
> forest vs. trees problem. The reverse engineering tool just provides
> one with a view of the lowest level of design, not the customer's view.
> (In fact, reverse engineering tool vendors must make specific
> assumptions about the intent just to provide a more abstract
> representation and those assumptions are not always even correct.)
>
> Perhaps the most insidious problem with reverse engineering is that it
> strongly encourages repeating the mistakes of the past. If an
> application is badly structured, reverse engineering just yields a bad
> model of what the application does. When one does not know what the
> requirements actually are, that bad structure can easily be interpreted
> as requirements.
>
> The most common reason to do reverse engineering to determine
> requirements is because one needs to replace an obsolete or
> unmaintainable systems that is not properly documented. In that
> situation I would go to the customer, elicit the requirements directly,
> and build the replacement as if it were new software. In such
> situations reverse engineering does not save any time and it can
> actually lead to a product that has many of the same problems as the
> original software.
>
>
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
> hsl@pathfindermda.com
> Pathfinder Solutions
> http://www.pathfindermda.com
> blog: http://pathfinderpeople.blogs.com/hslahman
> "Model-Based Translation: The Next Step in Agile Development". Email
> info@pathfindermda.com for your copy.
> Pathfinder is hiring:
> http://www.pathfindermda.com/about_us/careers_pos3.php.
> (888)OOA-PATH
Thank you Lahman, for sharing your thoughts .
> In that
> situation I would go to the customer, elicit the requirements directly,
> and build the replacement as if it were new software.
This is what in my mind. :-)
| |
|
| v4vijayakumar wrote:
>
> This is what in my mind. :-)
When you do, don't elicit the requirements all in a huge bunch. That
overloads customers, because nobody can predict everything the software
should and should not do.
Ask the customer what the most important requirements are, finish these in a
very short amount of time (hopefully one w ), and put the result online.
Then ask what the next requirements are. This procedure allows you to skip
all the requirements that turn out to be unneeded.
--
Phlip
[url]http://www.greencheese.us/ZLand[/url] <-- NOT a blog!!!
| |
| Vivekanandan M 2006-11-24, 3:59 am |
| Hello ,
> v4vijayakumar wrote:
> You see a software and wonder what requirements would have made someone
> to develop such a software. How we can identify the requirements from
> the working software product? What you call for this process of
> identifying requirements from the working software product? Reverse
> Engineering?
This is called as Reverse Engineering. Firstly your company will not
ask you to do this kind of work, as this is not legally correct.
Instead of doing a reverse engineering, think like a marketing guy,
what made him think a need for ... will be there in future! dont think
how that will be done!
Best Regards,
Vivekanandan M
| |
| Andrew Gabb 2006-11-25, 7:59 am |
| Phlip wrote:
> Ask the customer what the most important requirements are, finish these in a
> very short amount of time (hopefully one w), and put the result online.
> Then ask what the next requirements are. This procedure allows you to skip
> all the requirements that turn out to be unneeded.
It also means you get paid faster, which is great, because when you
realise that the architecture is totally inadequate, when the real
scope of the requirements emerges, you've still been paid even if
the project is then cancelled.
Or you can call it a 'prototype' and get paid to do it again, this
time with a new architecture. And again, and again. Some clients
fall for this one.
And the real slammer is that when the project is eventually
cancelled, or you get thrown out, you can blame it on the client for
changing his mind too much.
Those who can, elicit requirements and then design. Those who can't
start coding.
Andrew
--
Andrew Gabb
email: agabb@tpgi.com.au Adelaide, South Australia
phone: +61 8 8342-1021
-----
| |
|
| Andrew Gabb wrote:
> It also means you get paid faster, which is great, because when you
> realise that the architecture is totally inadequate, when the real scope
> of the requirements emerges, you've still been paid even if the project is
> then cancelled.
If you set the goal of making sure an end-user profits from your features,
as soon as possible, then you increase the odds of getting paid, and
decrease the odds of getting cancelled.
The best feedback is from users profiting from your code.
--
Phlip
[url]http://www.greencheese.us/ZLand[/url] <-- NOT a blog!!!
| |
| Andrew Gabb 2006-11-29, 8:01 am |
| Vivekanandan M wrote:
> This is called as Reverse Engineering. Firstly your company will not
> ask you to do this kind of work, as this is not legally correct.
> Instead of doing a reverse engineering, think like a marketing guy,
> what made him think a need for ... will be there in future! dont think
> how that will be done!
This aspect of reverse engineering is not illegal, any more than
copying a DVD is. It depends who wrote the software, who owns it,
and what license agreement if any is in place. Even then it would be
very interesting to see a test case if all you did was work out what
it did! It's what you do with that information that might get you
into a lawsuit.
In any case, looking at or using a software app to find out what it
does is never illegal if you have the rights to use it. Every day
clients check out products to see if they are compatible with their
needs. Is this illegal? Developers also check out their competitors'
software for functionality, performance, usability, etc. Again, not
illegal.
It's also one of the first steps in re-engineering an existing app
to work in a different (typically more modern) environment. Of
course you need requirements, scenarios, use cases, needs and
desires as well, but looking at the existing app will normally give
you some clues and help to validate your requirements.
Andrew
--
Andrew Gabb
email: agabb@tpgi.com.au Adelaide, South Australia
phone: +61 8 8342-1021
-----
|
|
|
|
|