REQUIREMENTS ENGINEERING IN IT PROJECTS AN OVERVIEW

Student: Arjan van der Laan Student-id: 2012097

CONTENTS
INTRODUCTION ...................................................................................................................... 3 1 2 3 4 PROJECT PHASES ............................................................................................................ 3 SOFTWARE DEVELOPMENT LIFECYCLE .................................................................. 3 REQUIREMENTS .............................................................................................................. 4 REQUIREMENTS PHASE ................................................................................................ 5 Planning .................................................................................................................................. 5 Development .......................................................................................................................... 5 Management ........................................................................................................................... 6 5 THE ROLE OF THE PROJECT MANAGER ................................................................... 7

CONCLUSION .......................................................................................................................... 8 BIBLIOGRAPHY ...................................................................................................................... 9

INTRODUCTION
Long before an IT project is initialized, there is just the customer and the business need. If we define the customer as a combination of the persons or entities that pay for and use the software, it is clear that these are the most important stakeholders. One of the aspects of calling project management successful is that the desired outcomes and results are achieved, for as much as they were written down in the contract between customer and contractor (Authencity Consulting LCC). This means a project is successful if everything that is agreed upon is achieved. Between the point where only the business need exists, and the project success, and possibly even before the project commences, an important step is to analyze these desired outcomes; the requirements. This paper attempts to give an overview what happens in the requirements phase, its role in project management and the authors opinion on the role of the project manager in this phase. The author will present an overview of the elements each project comprises, and from that zoom in on the requirements part.

1 PROJECT PHASES
Projects are generally divided into phases which together form the project life cycle. Each phase works towards achieving (delivering) a tangible and verifiable deliverable. An example of a deliverable would be a complete diagram design of the software that is to be delivered at the end of the lifecycle. Therefore, a deliverable can be verified before work is started on the next phase. Although this seems to imply that IT projects have only one activity at a time, this is not the case. In the development phase for example, several iterations of development can be worked on at the same time. Hence, phases might be rotating as iterations in e.g. software development, which will be elaborated on later in the text. Figure 1 shows an example of an IT project life cycle with its phases. Figure 1: Example of IT project life cycle

Define

Plan

Organize

Execute

Close

Each phase will somehow start with requirements. The requirements can be the outcome of an earlier phase or can have been set prematurely. The requirements are the basis of the phase; it defines what is needed, what the deliverable of the phase should be. In this paper, the term used for this phase is requirements engineering.

2 SOFTWARE DEVELOPMENT LIFECYCLE

If this phase model is applied to software development, two different types of project phasing emerge. Scientists have developed several different models for software development lifecycles, among which are the waterfall model, the iterative model, the spiral model and the agile model (Boehm, 1988; Muench, 1994; Highsmith, 2002; Beck, Beedle, van Bennekum,

& Cockburn, 2001). They differ in terms of when which element should be carried out, whether or not these should be carried out in sequence or simultaneously, and in how many pieces the development should be sliced. For example, in the waterfall model each element of the process is done in sequence, starting the next one when the previous one is completed. In iterative development there are several iterations, each containing all the development elements, responsible for only one building block of the software. Because of this, several can be done simultaneously and building is incrementally. The spiral model combines the idea of iterative development with the systematic aspects of the waterfall model. Each of the software development models is suitable for a specific type of project (depending on size, complexity, etc). Discussing all of the different methodologies is outside the scope of this paper; however, the models have common factors that each methodology needs to have for building whatever type of software. Figure 2 shows these factors. Figure 2: Factors common to software development projects
Requirements Specification Design Testing Deployment Maintenance

Architecture

Debugging

Implementation

(Wikipedia, 2012)

3 REQUIREMENTS
The introduction stated that project management success is when (among others) the contractually agreed outcomes are fulfilled. But project management success is not equal to project success. For example, for the project to be successful the clients problem also needs to be solved. On the other hand, we can say that a software project failed when the stakeholders are unhappy with the end result, and the software is not doing what the stakeholders wanted it to do. This can be because the project is done badly, or because the expectations were wrong. In this case the real requirements have not been defined well. To give a more specified meaning to the words requirement, a definition is provided. A requirement is a condition or capability that is needed by a stakeholder to either solve a problem, achieve an objective or that must be met to satisfy a formally imposed document (e.g. a contract, specification, etc.) (IIBA, 2009). There are 3 main types of requirements; business requirements, which are organizational goals and needs, user requirements, concerning the necessary tasks to perform with the software solution, and solution requirements. Solution requirements are functional or non-functional characteristics of the solution itself. Besides the main criteria, some authors use the term transition requirements to define temporarily needed capabilities during the development process

(Modernanalyst.com, 2012). These transition requirements are only valid for as long as the project takes. In this paper, the whole process surrounding requirements is called requirements engineering

4 REQUIREMENTS PHASE
Some scientists see developing requirements as something recurring throughout the project, either in each iteration or because at each phase a more detailed level of requirements is needed (Muench, 1994; Boehm, 1988). However, if you know that correcting defects during testing is already 10 times more expensive than correcting them during the requirement phase (Grady, 1999) you realize that the requirements need to be as clear as possible, as early as possible. Furthermore, a study conducted in 2005 among 2000 industry professionals showed that poor requirements definition accounted for 50 percent of failed projects (ESI International, 2006). Therefore, requirements engineering is very important for both the customer as well as the contractor. In this paper therefore the requirements development phase will be treated as preliminary to the rest of the project. Of course management of requirements happens during the whole project, the requirements may change during the process, and even new requirements may come, but their development should be done earlier. The requirements engineering phase exists according to the Business Analysis Body Of Knowledge (BABOK) of three main parts; the planning, the process of developing the requirements, and requirements management and communication, as is visible in Figure 3. Figure 3: Requirements engineering / business analysis according to the BABOK

(IIBA, 2009) Planning Business Analysis Planning describes how the requirements development part of the project can be carried out best, and what is necessary. Included tasks are the identification of stakeholders, choice of the technique to be applied and how to keep track of progress. Development Enterprise Analysis comprises clarifying the definition of the business need and defining a solution scope.

Elicitation is correctly and completely finding out what the needs of the stakeholders are (and checking this every time necessary). In this part answers have to be found on the questions Who, what, when, where, why and how?. Analysts, users, and other stakeholders sit together to build a list of requirements. In the Requirements Analysis part, the stated requirements are organized and analyzed to ensure that they are correct. This means organizing, prioritizing (very important!), specifying, modeling, verifying and validating the requirements. The outcome should be requirements that are within the specified scope and that precisely define the business need. Solution Assessment and Validation is somewhat outside of the requirements development process. It assesses the proposed solutions on whether they fit the need. Based on the outcome, gaps and shortcomings may be found and a change in the solution may be necessary. Once the solution is deployed, this process is repeated. Management Requirements Management and Communication is an umbrella process that affects the whole requirements development process. Approval, scope, traceability and re-use of requirements need to be managed and assessed throughout the process. Also management of conflicts and changes belong here, assuring agreement between stakeholders during the process. To give a better visualization of the boundary between the development part and the management part, Figure 4 shows the interpretation of this boundary as created by Wiegers (2003). Figure 4: Boundary line between requirements development and management

(Wiegers, 2003)

The goal of all these steps is to create documents that contain concrete information about the way users (need to) interact with the system, and the requirements of the software, so that these documents can serve as the basis of the project and, specifically, system engineering. One type of document is the backbone of the requirements engineering process. This type document is the use case. Use cases are lists of steps that present in a graphical way the interaction between roles (called actors which can be a human or an external system) and the system. Creating use cases starts at the requirements elicitation phase and has a big role in all subsequent phases. The other type of document which has an important role to play is the software requirements specification (SRS). This is a complete description of the behavior of the system that will need to be developed. Use cases are part of this specification, but it also includes nonfunctional requirements such as quality standards or design rules. After approval, this SRS is the end product of the requirements engineering phase in a project.

5 THE ROLE OF THE PROJECT MANAGER

In many cases, customers do not see and understand how essential it is to assure high quality requirements from the beginning (Wiegers, 2003). Yet their expectations are software with high quality. This means that the project manager (PM) has a very important role to play in this. The PM is not the one doing the actual development of the requirements development. That role belongs to the Business or Systems Analyst. So, what exact role should the PM play? How much should the PM be involved? The Project Management Body of Knowledge identifies the areas of importance for a PM: Project integration management Project scope management Project time management Project cost management Project quality management Project human resource management Project communications management Project risk management Project procurement management (PMI standard comittee, 1996)

If the PM bases his work on false requirements, he or she will fail in virtually all these areas and more importantly the final product. One of the competencies for a project manager is managing the expectations of the customer. By ensuring clear and correct definitions of requirements, the PM can ensure that not only he delivered what is agreed upon, but also solve the customers problem. Because, as elaborated on earlier, a successful project is not just when the PM did what is agreed upon, but also solve the real problem behind it. The real problem goes even further than the business need. Its about helping the customer in terms of

profitability or at least continuity. The project manager should always keep this in mind when reviewing requirements, even though he is not the one developing the requirements. Lastly, approval of prioritization of the requirements and the Software Requirements Specification as a whole should be managed by the PM as well.

CONCLUSION
The requirements phase of a project is a big factor of risk of failure and therefore a critical (preliminary) part of the project. It consists of planning, requirements development, and management and communication. The requirements development exists of enterprise analysis, elicitation, requirements analysis and solution assessment and validation. Because the quality of the requirements decide for such a big part the success of the project, a project manager has an important role to play in ensuring their quality.

BIBLIOGRAPHY
Authencity Consulting LCC. (n.d.). How to Define Project "Success". Authencity Consulting LCC. Bahill, A. T., & Henderson, S. J. (2004). Requirements Development, Verification and Validation Exhibited in Famous Failures. Systems Engineering, Vol. 8, No. 1. Beck, K., Beedle, M., van Bennekum, A., & Cockburn, A. (2001). Manifesto for Agile Software Development. Retrieved November 21, 2012, from agilemanifesto.org: http://agilemanifesto.org/ Boehm, B. (1988). A spiral model of software development and enhancement. Computer, 6172. ESI International. (2006). Eight Things Your Business Analysts Need to Know: A Practical Approach to Recognizing and Improving Competencies. Retrieved from http://www.vbhconsulting.com/Articles/BA-Competencies_white-paper_2-06[1].pdf Grady, R. B. (1999). An Economic Release Decision Model: Insights into Software Project Management. In Proceedings of the Applications of Software Measurement Conference (pp. 227-239). Orange Park, FL: Software Quality Engineering. Hickey, A. M., & Davis, A. M. (2003). Requirements Elicitation and Elicitation Technique Selection: A Model for Two Knowledge-Intensive Software Development Processes. Proceedings of the 36th Hawaii International Conference on System Sciences. Hawii: Computer Society. Highsmith, J. (2002). What is Agile Software Development? The Journal of Defense Software Engineering, 4-9. IIBA. (2009). The Guide to the Business Analysis Body of Knowledge. Toronto, Canada: International Institute of Business Analysis (IIBA). Jackson, K., Dick, J., & Hull, E. (2010). Requirements Engineering (3rd ed. ed.). London: Springer. Leffingwell, D., & Widrig, D. (2003). Managing software requirements: a use case approach. Boston, U.S.A.: Pearson Education, Inc. Modernanalyst.com. (2012). Interview questions for Business Analysts and System Analysts. Retrieved May 23, 2012, from ModernAnalyst.com`: http://www.modernanalyst.com/Careers/InterviewQuestions/tabid/128/Default.aspx?A rticleType=ArticleView&ArticleID=2033 Muench, D. (1994). The Sybase Development Framework. Oakland, CA: Sybase Inc.

PMI standars comittee. (1996). A Guide To The Project Management Body Of Knowledge. Newton Square, PA, USA: Project Management Institute. Sommerville, I., & Kotonya, G. (1998). Requirements engineering. London: John Wiley & sons. Wiegers, K. E. (2003). Software Requirements, 2nd Edition. Microsoft Press. Wikipedia. (2012, 11 22). Software development process. Retrieved 11 22, 2012, from wikipedia.org: http://en.wikipedia.org/wiki/Software_development_process