Information Technology (IT) Requirements Management (REQM) For Development

Information technology requirement management (IT Management) is the process whereby all resources related to information technology are managed according to a organization’s priorities and needs. This includes tangible resources like networking hardware, computers and people, as well as intangible resources like software and data. The central aim of IT management is to generate value through the use of technology. To achieve this, business strategies and technology must be aligned. Information technology management includes many of the basic functions of management, such as staffing, organizing, budgeting and control, but it also has functions that are unique to IT, such as software development, change management, network planning and tech support. Generally, IT is used by organizations to support and compliment their business operations. The advantages brought about by having a dedicated IT department are too great for most organizations to pass up. Some organizations actually use IT as the center of their business. The purpose of requirements management is to ensure that an organization documents, verifies, and meets the needs and expectations of its customers and internal or external stakeholders. Requirements management begins with the analysis and elicitation of the objectives and constraints of the organization. Requirements management further includes supporting planning for requirements, integrating requirements and the organization for working with them (attributes for requirements), as well as relationships with other information delivering against requirements, and changes for these. The traceability thus established is used in managing requirements to report back fulfilment of company and stakeholder interests in terms of compliance, completeness, coverage, and consistency. Traceabilities also support change management as part of requirements management in understanding the impacts of changes through requirements or other related elements (e.g., functional impacts through relations to functional architecture), and facilitating introducing these changes. Requirements management involves communication between the project team members and stakeholders, and adjustment to requirements changes throughout the course of the project. To prevent one class of requirements from overriding another, constant communication among members of the development team, is critical. For example, in software development for internal applications, the business has such strong needs that it may ignore user requirements, or believe that in creating use cases, the user requirements are being taken care of.

The major IT Requirement Management Phases

Investigation

• In Investigation, the first three classes of requirements are gathered from the users, from the business and from the development team. In each area, similar questions are asked; what are the goals, what are the constraints, what are the current tools or processes in place, and so on. Only when these requirements are well understood can functional requirements be developed. In the common case, requirements cannot be fully defined at the beginning of the project. Some requirements will change, either because they simply weren’t extracted, or because internal or external forces at work affect the project in mid-cycle. The deliverable from the Investigation stage is requirements document that has been approved by all members of the team. Later, in the thick of development, this document will be critical in preventing scope creep or unnecessary changes. As the system develops, each new feature opens a world of new possibilities, so the requirements specification anchors the team to the original vision and permits a controlled discussion of scope change. While many organizations still use only documents to manage requirements, others manage their requirements baselines using software tools. These tools allow requirements to be managed in a database, and usually have functions to automate traceability (e.g., by enabling electronic links to be created between parent and child requirements, or between test cases and requirements), electronic baseline creation, version control, and change management. Usually such tools contain an export function that allows a specification document to be created by exporting the requirements data into a standard document application.

Feasibility

• In the Feasibility stage, costs of the requirements are determined. For user requirements, the current cost of work is compared to the future projected costs once the new system is in place. Questions such as these are asked: “What are data entry errors costing us now?” Or “What is the cost of scrap due to operator error with the current interface?” Actually, the need for the new tool is often recognized as this questions come to the attention of financial people in the organization. Business costs would include, “What department has the budget for this?” “What is the expected rate of return on the new product in the marketplace?” “What’s the internal rate of return in reducing costs of training and support if we make an new, easier-to-use system?” Technical costs are related to software development costs and hardware costs. “Do we have the right people to create the tool?” “Do we need new equipment to support expanded software roles?” This last question is an important type. The team must inquire into whether the newest automated tools will add sufficient processing power to shift some of the burden from the user to the system in order to save people time. The question also points out a fundamental point about requirements management. A human and a tool form a system, and this realization is especially important if the tool is a computer or an new application on a computer. The human mind excels in parallel processing and interpretation of trends with insufficient data. The CPU excels in serial processing and accurate mathematical computation. The overarching goal of the requirements management effort for a software project would thus be to make sure the work being automated gets assigned to the proper processor. For instance, “Don’t make the human remember where she is in the interface. Make the interface report the human’s location in the system at all times.” Or “Don’t make the human enter the same data in two screens. Make the system store the data and fill in the second screen as needed.” The deliverable from the Feasibility stage is the budget and schedule for the project.

Design

• Assuming that costs are accurately determined and benefits to be gained are sufficiently large, the project can proceed to the Design stage. In Design, the main requirements management activity is comparing the results of the design against the requirements document to make sure that work is staying in scope. Again, flexibility is paramount to success. Here’s a classic story of scope change in mid-stream that actually worked well. Ford auto designers in the early ‘80s were expecting gasoline prices to hit $3.18 per gallon by the end of the decade. Midway through the design of the Ford Taurus, prices had centered to around $1.50 a gallon. The design team decided they could build a larger, more comfortable, and more powerful car if the gas prices stayed low, so they redesigned the car. The Taurus launch set nationwide sales records when the new car came out, primarily, because it was so roomy and comfortable to drive. In most cases, however, departing from the original requirements to that degree does not work. So the requirements document becomes a critical tool that helps the team make decisions about design changes

Construction and test

• In the construction and testing stage, the main activity of requirements management is to make sure that work and cost stay within schedule and budget, and that the emerging tool does in fact meet requirements. A main tool used in this stage is prototype construction and iterative testing. For a software application, the user interface can be created on paper and tested with potential users while the framework of the software is being built. Results of these tests are recorded in a user interface design guide and handed off to the design team when they are ready to develop the interface. This saves their time and makes their jobs much easier.

Requirements change management

• Hardly would any software development project be completed without some changes being asked of the project. The changes can stem from changes in the environment in which the finished product is envisaged to be used, business changes, regulation changes, errors in the original definition of requirements, limitations in technology, changes in the security environment and so on. The activities of requirements change management include receiving the change requests from the stakeholders, recording the received change requests, analyzing and determining the desirability and process of implementation, implementation of the change request, quality assurance for the implementation and closing the change request. Then the data of change requests be compiled analyzed and appropriate metrics are derived and dovetailed into the organizational knowledge repository.

Release

• Requirements management does not end with product release. From that point on, the data coming in about the application’s acceptability is gathered and fed into the Investigation phase of the next generation or release. Thus the process begins again.

The relationship/interaction of requirements management process to the Software Development Lifecycle (SDLC) phases

Planning

• Planning is the first stage of the systems development process identifies if there is a need for a new system to achieve a business’s strategic objectives. Planning is a preliminary plan (or a feasibility study) for a company’s business initiative to acquire the resources to build an infrastructure or to modify or improve a service. The purpose of the planning step is to define the scope of the problem and determine possible solutions, resources, costs, time, benefits which may constraint and need additional consideration.

Systems Analysis and Requirements

• Systems Analysis and requirements is the second phase is where businesses will work on the source of their problem or the need for a change. In the event of a problem, possible solutions are submitted and analyzed to identify the best fit for the ultimate goal(s) of the project. This is where teams consider the functional requirements of the project or solution. It is also where system analysis takes place—or analyzing the needs of the end users to ensure the new system can meet their expectations. The systems analysis is vital in determining what a business’ needs, as well as how they can be met, who will be responsible for individual pieces of the project, and what sort of timeline should be expected. There are several tools businesses can use that are specific to the second phase. They include:
• CASE (Computer Aided Systems/Software Engineering)
• Requirements gathering
• Structured analysis

Systems Design

• Systems design describes, in detail, the necessary specifications, features and operations that will satisfy the functional requirements of the proposed system which will be in place. This is the step for end users to discuss and determine their specific business information needs for the proposed system. It is during this phase that they will consider the essential components (hardware and/or software) structure (networking capabilities), processing and procedures for the system to accomplish its objectives.

Development

• Development is when the real work begins—in particular, when a programmer, network engineer and/or database developer are brought on to do the significant work on the project. This work includes using a flow chart to ensure that the process of the system is organized correctly. The development phase marks the end of the initial section of the process. Additionally, this phase signifies the start of production. The development stage is also characterized by instillation and change. Focusing on training can be a considerable benefit during this phase.

Integration and Testing

• The Integration and Testing phase involves systems integration and system testing (of programs and procedures)—normally carried out by a Quality Assurance (QA) professional—to determine if the proposed design meets the initial set of business goals. Testing may be repeated, specifically to check for errors, bugs and interoperability. This testing will be performed until the end user finds it acceptable. Another part of this phase is verification and validation, both of which will help ensure the program is completed.

Implementation

• The Implementation phase is when the majority of the code for the program is written. Additionally, this phase involves the actual installation of the newly-developed system. This step puts the project into production by moving the data and components from the old system and placing them in the new system via a direct cutover. While this can be a risky (and complicated) move, the cutover typically happens during off-peak hours, thus minimizing the risk. Both system analysts and end-users should now see the realization of the project that has implemented changes.

Operations and Maintenance

• The seventh and final phase involve maintenance and regularly required updates. This step is when end users can fine-tune the system, if they wish, to boost performance, add new capabilities or meet additional user requirements.

Interaction Of Requirements Management Process To The Change Management

Every IT landscape must change over time. Old technologies need to be replaced, while existing solutions require upgrades to address more demanding regulations. Finally, IT needs to roll out new solutions to meet business demands. As the Digital Age transforms many industries, the rate of change is ever-increasing and difficult for IT to manage if ill prepared.

Requirements baseline management

Requirements baseline management can be the single most effective method used to guide system development and test. This paper presents a proven approach to requirements baseline management, requirements traceability, and processes for major system development programs. Effective baseline management can be achieved by providing: effective team leadership to guide and monitor development efforts; efficient processes to define what tasks needs to be done and how to accomplish them; and adequate tools to implement and support selected processes. As in any but the smallest organization, useful engineering leadership is essential to provide a framework within which the rest of the program’s engineering staff can function to manage the requirements baseline. Once, a leadership team, is in place, the next task is to establish processes that cover the scope of establishing and maintaining the requirements baseline. These processes will form the basis for consistent execution across the engineering staff. Finally, given an appropriate leadership model with a forward plan, and a collection of processes that correctly identify what steps to take and how to accomplish them, consideration must be given to selecting a toolset appropriate to the program’s needs.

Use Cases Vs. Requirements

• Use cases attempt to bridge the problem of requirements not being tied to user interaction. A use case is written as a series of interactions between the user and the system, similar to a call and response where the focus is on how the user will use the system. In many ways, use cases are better than a traditional requirement because they emphasize user-oriented context. The value of the use case to the user can be divined, and tests based on the system response can be figured out based on the interactions. Use cases usually have two main components: Use case diagrams, which graphically describe actors and their use cases, and the text of the use case itself.
• Use cases are sometimes used in heavyweight, control-oriented processes much like traditional requirements. The system is specified to a high level of completion via the use cases and then locked down with change control on the assumption that the use cases capture everything.
• Both use cases and traditional requirements can be used in agile software development, but they may encourage leaning heavily on the documented specifications of the system rather than collaboration. I have seen some clever people who could put use cases to work in agile situations. Since there is no built-in focus on collaboration, it can be tempting to delve into a detailed specification, where the use case becomes the source of record.

Definitions of  types of requirements

Requirements types are logical groupings of requirements by common functions, features and attributes. There are four requirement types :

Business Requirement Type

• The business requirement is written from the Sponsor’s point-of-view. It defines the objective of the project (goal) and the measurable business benefits for doing the project. The following sentence format is used to represent the business requirement and helps to increase consistency across project definitions:
  • “The purpose of the [project name] is to [project goal — that is, what is the team expected to implement or deliver] so that [measurable business benefit(s) — the sponsor’s goal].”

Regression Test requirements

• Regression Testing is a type of software testing that is carried out by software testers as functional regression tests and developers as Unit regression tests. The objective of regression tests is to find defects that got introduced to defect fix(es) or introduction of new feature(s). Regression tests are ideal candidates for automation.

Reusable requirements

• Requirements reusability is defined as the capability to use in project requirements that have already been used before in other projects. This allows optimizing resources during development and reduce errors. Most requirements in today’s projects have already been written before. In some cases, reusable requirements refer to standards, norms and laws that all the projects in a company needs to comply with, and in some other, projects belong to a family of products that share a common set of features, or variants of them.

System requirements:

• There are two type of system requirements

Functional Requirement Type

• The functional requirements define what the system must do to process the user inputs (information or material) and provide the user with their desired outputs (information or material). Processing the inputs includes storing the inputs for use in calculations or for retrieval by the user at a later time, editing the inputs to ensure accuracy, proper handling of erroneous inputs, and using the inputs to perform calculations necessary for providing expected outputs. The following sentence format is used to represent the functional requirement: “The [specific system domain] shall [describe what the system does to process the user inputs and provide the expected user outputs].” Or “The [specific system domain/business process] shall (do) when (event/condition).”

Nonfunctional Requirement Type

• The nonfunctional requirements define the attributes of the user and the system environment. Nonfunctional requirements identify standards, for example, business rules, that the system must conform to and attributes that refine the system’s functionality regarding use. Because of the standards and attributes that must be applied, nonfunctional requirements often appear to be limitations for designing an optimal solution. Nonfunctional requirements are also at the System level in the requirements hierarchy and follow a similar sentence format for representation as the functional requirements: “The [specific system domain] shall [describe the standards or attributes that the system must conform to].”