Requirements Engineer
Every software student knows about the software development life cycle. Computer Science program teaches it and every project manager and developer know that they must follow the life cycle phases. Whether you are an entry level developer working on first projects or experienced developer, you always follow the life cycle. At least, in theory but in practice, people may not always follow it. When they do not have time, they skip a phase. When the project is late, project manager orders the team to start coding, ignores design phase or skips testing phase. Even when they follow the lifecycle phase, they did not completely finish it. Each phase ends with the creation of a document or product to record the work and decisions that were made. These documents must be validated for completeness before starting the next phase but most teams often hurrying to move on rather than complete the phase accordingly.
The development life cycle always starts with the customer needs. This is the reason why you start a software project. Without customer, there is no project. Understand customer’s need is the most important activity of software project. Of course, some customers are good at explaining their needs but some are not. Most customers will explain their business problems and want the team to solve it. In order to do that, the project team must takes time to understand the business problems but most software teams often ignore this fact. They confuse what customer said is the real requirements. Without a clear understand of customer’s needs but hurry to develop software is the key reason why software projects often fail. They do not know that customers often express their needs in term of their business, sometime they mix what they need with what they want. Sometime they even mix what they want with solution that they believe will solve their problems.
To stop this confusion, project team must have a requirements engineer or business analyst to work with customers to understand their problems and document them in a “Customer requirements document”. This is NOT a Software Requirements Specification (SRS) as many developers often thought. By write down what the customer say, the requirements engineer demonstrates the understanding of the requirements as stated by the customer. This “Customer requirements document” is only a proof that the customer needs have been collected and understood. This gives the customer a good feeling that they have been listened to and that the software team has the knowledge to work on the solution. The “Customer requirements document” must be reviewed, analyzed, validated, and approved by the customer before it is transformed into a “Software Requirements Specification” (SRS) which is written for the development team. This is the result of the requirements phase and only when it is fully validated and approved, the team can move to the next phase.
A requirements validation activity is a description of what is to be produced and how it will work. To ensure that the team understands what customer needs. Sometime it is important to develop a prototype at this phase so that the requirements can easily be understood by both the users and the developers. The prototype can be as simple as a sequence of screen created for the users to see or a small application to demonstrate a proof of concept on how the software will be built. The important thing is that there is discussion between the developers and the customer to accurately state the requirements and agree what will be produced.
The skill of working with customer is the most important skill that many developers do not have. The discussion with customers to understand their needs and document into customer requirements is not an easy task. The analysis of what customer said and distinguishes between what they need and what they want is another skill that many developers do not have. The transformation of customer business requirements into a software requirements specification is another skill that few have. Unfortunately, most computer science training programs only focus on programming knowledge over other life cycle activities. Even the role of the requirements engineer (also called business analyst, systems analyst) is not even mention in text books as companies still expect software developers or project managers to perform this function. Today only few Software Engineering programs teach this skill. My question is why an important role that can determine a project success is not well taught or well known?
Sources
- Blogs of Prof. John Vu, Carnegie Mellon University
