 Felix Holzke is Lead Consultant at NTT DATA Germany and specialist for Requirement Engineering in large-scale projects. |
|
 Dr. Jens Kawelke is Head of the Competence Unit Requirements Engineering at NTT DATA Germany. He consults clients regarding the Requirements Engineering methodology and offers Requirements Engineering training for clients and internal staff. |
1.1 Why do IT projects fail?
Alreaday back in 2004 Standish Group [Standish Group (2004). CHAOS Report (Report). West Yarmouth, Massachusetts: Standish Group] found out that the average cost overrun for IT projects was 43 percent and that 71 percent of projects were over budget, time, and under scope.
This cost overrun can be tracked down to the main reason 'scope creep' [https://en.wikipedia.org/wiki/Scope_creep], which simply means not delivering what the business customer had originally in mind and thus causing considerable rework.
In order to prevent that, the project goal and its detailed requirements have to be determined and constantly checked against the customer's ideas. The set of techniques to achieve this is called Requirements Engineering (RE), which also deals with handling other issues leading to project failure such as poor communication or the lack of stakeholder involvement.
In one word: Poor RE is a major cause of project failure.
1.2 Examples of project failure
Let us start with an artificial example of a missing basic requirement: A business customer is asking for an ultimatively-small smart phone to be constructed. Without specifying that the keypad touch screen to enter text and the display must be on the same side of the phone, this not documented requirement might lead to a non-usable smartphone and tons of rework.
One well known real example for poor RE is the accident of the Ariane 5 rocket in 1996 exploding 37 seconds after liftoff. Reason for this was a broken code fragment, which was required on earlier rockets, but was not required anymore after liftoff on Ariane 5. Professional RE would have recognized the code fragment as to be removed, since it did not satisfy any (traceable) requirement.
1.3 How would professional RE improve projects?
As there are numerous additional benefits, we shall focus onsome key points:
- You can better manage scope creep. RE focuses on detailing requirements unambigiuously before putting effort in developing the wrong artifacts or estimating too little effort. This avoids wrong expectations and request for rework and is a big step towards finishing the project "in budget".
- You can better judge the impact of changes. Since the change of requirements in the course of implementing large products is quite inevitable, one should be able to easily derive what parts of the already-built product along with its artifacts such as test cases will have to be modified. Professional RE enables the customer to prioritize his request appropriately.
- The Requirements Engineer speaks the "language" of both - the customer and the programmers. The requirements, gathered from the customer are documented in a structured way so, that the programmers can implement their artifacts straight-away without further time-consuming enquiries to the customer.
- Especially in large software projects, well documented requirements make it easier for new project members to understand functionality that was implemented years ago.
- You can better manage quality assurance. Quality of the software product can be verified through automatically derived test scenarios if requirements have been documented in an appropriate way.
1.4 What is the key success factor in introducing Requirements Engineering in order to improve project success?
In order to achieve better results in RE, organizations should focus on training their business analysts to stick to a common methodology, i.e develop their skills or hire trained people. Most important skills are
- analytical competencies,
- active listening,
- phrasing requirements without ambiguities,
- communication skills, especially for dealing with conflicts.
Especially when it comes to crossing different time zones with many team members, who speak different languages, it becomes more important to document and distribute requirements in a structured and unambiguous way and in writing.
Since RE is an interconnected discipline, it requires top management support for the organization as a whole or at least the project manager.
1.5 What are the disciplines Requirements Engineering deals with?
In order to achive projects goals professional RE contains techniques for
- collecting requirements from different sources like people (stakeholders), existing documents or existing systems. There are many techniques that can be used in different situations, e.g. interviews or observing techniques (stakeholders), system archeology (existing systems), perspective-based reading (existing documents)- documenting the collected requirements, e.g. by writing unambigiously phrased natural-language sentences in well-structured form that show different perspectives on the IT system to be developed. Or it represents requirements in standardized graphical (UML-based) models that make them easier to understand even by non-trained business users.
- validating that requirements are what the business customer had in mind. Which can be as easy as presenting an automatically-built clickable software prototype derived from the requirements model. Recognizing wrong requirements early, saves costs compared to late recognition when code and test cases have already been created.
- managing requirements through their lifecycle and track how they interconnect from the first idea to the final tested line of code.
The RE techniques [see above graphic] can be considered part of an RE lifecycle since they are applied recurrently and in a strongly iterative manner.
Where is RE located in common Software Engineering Lifecycles? [see figure below]
We see Requirements Engineering as a subdiscipline of Business Analysis (BA). BA also deals with defining requirements of organization processes or needs (business process management), wheras RE deals with detailing the requirements to build an IT system, which helps to achieve those business goals. Sometimes the business process analysis and optimization are considered part of the Software Engineering Lifecycle. In agile projects the steps from RE to Test will be passed through in cycles, in waterfall projects in a linear manner as shown above in [see the above figure].
1.6 How can I "professionalize" Requirements Engineering?
Besides of training people in the aspects mentioned above, external consultants can help to overcome such a skill gap in an organization. Although people with the appropriate Requirements Engineering skills can help to implement the core techniques, it becomes difficult for humans to handle the amount of requirements for large-scaled systems. RE can be supported by various IT tools:
- Requirements from legacy systems can be easily collected using code analysis tools which create graphical representations of legacy COBOL code. These can later be reused for the requirements documentation of a new modern IT system from scratch.
- The whole lifecycle of a requirement can be documented and tracked in a Requirements Management (RM) tool. Compared to Word and Excel documents, RM tools enable you to document and trace an idea either in natural language or with graphical elements up to the test case. And it enables many collaborators to work efficiently in parallel on the overall versioned collection of your company's IT requirements including digital approval processes.
- Requirements validation can effectively be supported by tools that analyze your textual requirements if they are conform to certain rules for well-formulated requirements. It can be as easy as eliminating ambigious words like 'fast', 'flexible', 'simple', or 'robust' which do not quantitatively reflect what is required.
3663 views
