I often read in specifications that the new system should behave like the old one. But how does the old one behave? If you don't have a corresponding specification, you're just fishing in murky waters. Often, the knowledge is lost within the company, and no one really remembers it anymore. It's actually totally obvious. Anyone who has already developed a similar product will base their new development on the existing one. But what do you do if the old product has no specifications or only inadequate ones?
Reverse requirements engineering
If the specification doesn't provide much information, then reverse requirements engineering is the answer. While requirements engineering specifies what is to be built, reverse requirements engineering takes the opposite approach: extracting the requirements from the system.
- What features does the system have?
- What interfaces does it have?
- How does it behave?
- What non-functional requirements should the system meet?
Step by step, the status quo is defined. It's often helpful to consult the user manual. This is where you'll find useful information about the system. The user manual helps you use the correct terms during reverse engineering. These terms can be used for the glossary. The user manual describes the technical specifications and functionality. This information can also be directly converted into requirements.
|
|
| Dipl.-Ing. Goran Madzar, Partner, Senior Systems Engineer E-mail: madzar@medtech-ingenieur.de Phone: +49 9131 691 240 |
|
Do you need support with the development of your medical device? We're happy to help! MEDtech Ingenieur GmbH offers hardware development, software development, systems engineering, mechanical development, and consulting services from a single source. Contact us. |
|
Old is not new
It's important to understand that the requirements for the legacy product aren't necessarily the same as the requirements for the new system being developed. Therefore, the requirements identified through reverse requirements engineering should be treated with caution. After all, you don't want to build the same old thing, but something new. Nevertheless, the legacy system is a good source of requirements. The goal should be to create requirements of such quality that they can be incorporated into the next project. Reverse engineering is never a good idea in and of itself; it's the only way to get back on track when information is missing. Under no circumstances should you accept a requirement like "The system should behave like the legacy system"! Such a statement helps no one and only leads to problems in the long run.
What are your experiences with reverse requirements engineering? I'd be happy if you'd contact me or leave a comment.
Best regards
Goran Madzar