It’s frequently belitted and often overlooked. But like it or not, its one of the most important phases of any engineering project!
There are lots of aspects of engineering which are exciting, fun and rewarding. Innovative designs, detailed testing and technical challenges are all things we live for as engineers. And then there’s requirements engineering. There aren’t too many people out there who love requirements engineering (if you are one of the select few, say hello in the comments!) and yet, it is one of the most important phases of any engineering project.
The first stage of requirements engineering is all about discovering the purpose for carrying out a project at all. The next is about defining any design constraints and documenting everything clearly. Identifying stakeholders and their needs, and documenting all of this in a form which is easy to understand and communicate is no mean feat. However, this investment up front before any of the so called “real engineering” begins is incredibly important. Understanding what your stakeholders say they want, as well as what they really want, gives you a fighting chance later on in the project to make the right decisions and to deliver a solution that fits. With any engineering design project, it’s not enough to build the thing right. You need to build the right thing.
If the requirements engineering phase isn’t carried out properly at the start of a project it can be really difficult to get people on the same page. Without a watertight requirements specification to work from, much of the design is left to assumptions and subjectivity. As I’m sure you already know, that isn’t good!
A perfect example of requirements engineering not being done well was the Mars Climate Orbiter mishap in 1999. The Orbiter, which cost $125 million, was lost because one software team was working in imperial units and another in metric units. Now, this mistake should have been picked up and corrected during the integration and testing phases of the project, but a detailed requirements specification for the problematic software module might have been enough to prevent the mistake in the first place (you can read the full report on the incident here.
If you compare that with the recent success of Curiosity (I couldn’t resist another picture of it!), it’s amazing to see how such little things can have such profound consequences.
So, even if you find it one of the least exciting parts of your work, make sure you pay attention to requirements engineering. A solid requirements specification will give a firm foundation for the rest of your project. Don’t forget to say hello in the comments if you’re a big requirements engineering fan!The Importance Of Requirements Engineering,
No related posts.