Requirements Engineering

Understanding customer business goals and objectives are key to successful software requirements engineering. While improvements in software development methodologies have increased overall quality, companies continue to face challenges in identifying, communicating and managing information system project requirements.

Organizations typically gather, analyze and approve requirements in the project’s Definition phase without the involvement of a qualified requirements “engineer.” Consequently, more detailed requirements and further clarifications are often needed when these initial requirements are shared with service suppliers tasked with undertaking solution development. The need to revisit requirements often prevents or delays delivery of solutions, decreases anticipated business value and increases cost. The International Conference on Software Engineering (ICSE) estimates that 40 percent of requirements in a typical project generate rework at some point during a project life cycle.

Software development is the process of taking abstract concepts that are captured in requirements and further refining until a product is created. This refinement occurs in the life cycle naturally with many steps each adding more detail to the abstraction about it. So naturally, there will be changes to the abstraction above as the refinement captures more details about how the product is to be created.

This can be seen by the following: As you analyze the high-level requirements for software, you then make design choices, like UML class diagrams, to determine how to implement the requirements. The UML class diagram will be refined further as you make lower-level design choices, like which class gets implemented on what platform (client, server, n-tier). Each of these choices impacts, and adds to, “what ultimately becomes the requirements for the software.” Some of the requirements are business requirements, platform requirements, security requirements, technical development requirements and so forth.