Requirements are the basis for design and the whole product development process. The development of requirements includes planning for elicitation, elicitation, analysis, specification development, validation, and communication to the customer to get acceptance.
Requirements, which are received or generated by the project team, including both technical and non-technical requirements as well as those requirements, levied on the project by the organization, should be administrated and tracked carefully. Requirements are identified and refined during the phases of the project life cycle. Design decisions, subsequent corrective actions, and feedback during each phase of the product’s life cycle are analyzed for impact on derived and allocated requirements. Administration is required especially to keep track of the proposed changes against the agreed-upon set of requirements after the analysis phase.
When a project receives requirements from an approved requirements provider, the requirements are reviewed with the requirements provider to resolve issues and prevent misunderstanding before the requirements are incorporated into the project’s plans. Once the requirements provider and the requirements receiver reach an agreement, commitment to the requirements is obtained from the project participants. The project manages changes to the requirements as they evolve and identify any inconsistencies that occur among the plans, work products, and requirements.
The involvement of relevant stakeholders in requirements development, analysis and administration gives them visibility into the evolution of requirements. This activity continually assures them that the requirements are being properly defined.
The clear and consistent requirements will be used as a basis for development planning, product design and acceptance test planning. The product architecture is developed as a high level design, and then the detailed design is performed to provide all of the information needed to produce, code, or otherwise implement the design as a product or product component.
Testing activities can be applied to all aspects of the product in any of its intended environments, such as operation, training, maintenance, and support services. The methods employed to accomplish testing can be applied to work products, as well as to the product and product components. The testing environments should represent the intended environment for the product and product components. Testing demonstrates that the product, as provided, will fulfill its intended use.
Testing can be applied in different levels and in different product life cycle phases. The product development process will conduct unit testing on individual components, integration testing for all product components together, system testing on the whole system before delivering to the customer and finally acceptance testing on customer side. Formal releasing mechanisms should be followed before the delivering and acceptance tests undertaken to provide clear visibility and tracking ability on the delivered product.
After successful product delivery to the customer, a post-mortem type work starts. The purpose of post-mortem activities are to collect and analyze the gained experiences during the project to facilitate the future enactment of the process in better way.
This set of goals that will be satisfied by performing this process:
· Goal 1: Requirements are administrated and tracked to all product components during all project phases.
· Goal 2: Stakeholders’ needs, expectations, constraints, and interfaces are elicited, analyzed, and stated as clear requirements, which are refined and elaborated to develop validated requirements specifications.
· Goal 3: Product architecture are selected and clear defined, which are used to develop product-component detailed designs.
· Goal 4: Product components, and associated support documentation, are implemented from their designs.
· Goal 5: Preparation for testing, in all types and product life cycle phases, is conducted, and then product or product components are tested to ensure that they are suitable for use in their intended operating environment.
· Goal 6: Preparation for product releasing is conducted, which lead to deliver complete tested system to the customer for acceptance.
This is the set of polices that guide this process.
· Eliciting the requirements from the customers, users and even the organization.
· Ensure that the elicited requirements are complete and consistent.
· Ensure that the developed software specifications correctly express the requirements and will result in the intended functionality of the software.
· Ensure that all requirements management activates for the projects developed within the project management’s authority are enacted in accordance to this policy.
· Ensure that the requirement documents are included in the project’s configuration management activities.
· Designating project personnel to enact the requirements management activities, and ensure that involved personnel in requirements management activities are qualified and properly trained to pursue their allocated responsibilities.
· Documenting required changes to existing software via proper change management cycle.
· Providing the acceptance criteria for evaluating the final product and verifying that the approved requirements are integrated in the new product release.
· The software product is traceable to the Software Requirements Specification (SRS) which is considered as a starting point.
· The software development plan should address the software product activities as early as possible in SDLC and testing activities should start as early as possible.
· Members of the software engineering technical staff should receive the required training/orientation to perform their technical assignments.
The product development process consists of large number for procedures that work in harmony during the project life cycle to reach the goals of the process and the project. The interaction between these procedures is carried out through four different ways; direct leading, required rework, calling, and conducting changes during the save channel. The following is a list of the procedures in the product development process.
Requirements Planning (RITSOL_PD_Requirmenet_Elicitation_Plan_Template_V1.2)
The objective of the requirements planning procedure is to guide the enactment of the requirements elicitation process. The procedure involves establishing an agreement among the project’s stakeholders on who will do what, and by when the process tasks should be accomplished.
Requirements Elicitation (guided by RITSOL_PD_Requirmenet_Elicitation_Plan_Template_V1.2)
The objective of the elicitation procedure is to discover and capture candidate software requirements (both functional and non-functional) by communicating with the customer and/or end users and others who have stake in the system development. There are several techniques to elicit requirements these techniques which include brainstorming, interviews, questionnaires and focus groups.
The objective of the analysis procedure is to further understand the requirements to resolve conflicts and inconsistencies and to ensure that they meet the required quality attributes and reflect the customer needs. The procedure also involves negotiation among stakeholders to agree on a set of requirements. Tasks of this procedure will likely be repeated several times until an agreement is reached.
The objective of the requirements development procedure is to transform identified requirements into a formal software requirement specification document. The result of the formalization procedure is a document, Software Requirements Specifications (SRS), which is used to communicate requirements among all stakeholders.
The objective of the validation procedure is to ensure that the developed SRS reflects the customer requirements. The process involves communicating SRS to all stakeholders and facilitating agreement among them.
The objective of the acceptance process is to confirm that the baseline requirements reflect the project’s acceptance criteria. This procedure can also be used as a milestone to report progress to the customer and senior management.
The objective of the requirements administration process is to ensure that all requirements are traceable and under control. The procedure mainly involves administrating and maintaining the requirements database in addition to the requirements traceability. This procedure is needed when any changes to the approved SRS occur. The change may be a modification in an old requirement or as a new one.
Development Planning (RITSOL_PD_Product_Development_Plan_Template_V1.2)
The objective of this process is to establish a reasonable plan for performing development activities and to be involved in the project from the initial stages which will provide a strong infrastructure for the project's success. Product development team will share the planning of the project with the other stakeholders. Selecting the appropriate software development life cycle is an important step. The project deliverables and estimation of the product size and effort will be shared with other team members.
Architecture Designing (RITSOL_PD_Architectural_Design_Template_V1.2)
The objectives of the design process are to develop a coherent, well-organized representation of the software product that meets the customer’s requirements and satisfies the predefined quality criteria. The process comprises the architectural design that will be followed by the detailed design in the next procedure. Architectural design provides the infrastructure for this detailed design. The importance of software design can be defined with the phrase, ‘quality design is the place where quality is fostered in software engineering’. It is an iterative process through which requirements are translated into a ‘blueprint’ for constructing the software.
Detailed Designing (RITSOL_PD_Detailed_Design_Template_V1.2)
Architectural design and detailed design are usually carried out in sequence because detailed design is largely dependent on the architectural design. Detailed design provides the basis for the product implementation.
The objective of the implementation procedure is the transformation of the detailed design representation into a programming language realization by applying the appropriate coding standard and to develop the required product documentation to support the coded product. The code will be grouped into units (this will be dictated by the selected language and design information). All units shall be transformed into executable code to be debugged. Incorrect code and other product component will be re-worked until run free of errors.
The unit test is a procedure used to validate that a particular module of source code is working properly. The procedure is to write test cases for all functions and methods so that whenever a change causes a regression, it can be quickly identified and fixed. Ideally, each test case is separate from the others. This type of testing is mostly done by the developer/tester and not by end-users. The goal of unit testing is to isolate each part of the program and show that the individual parts are correct.
Integration testing is the phase of software testing in which individual software modules are combined and tested as a group. It follows unit testing and precedes system testing. Integration testing takes ‘modules’ as its input. These modules have been checked out by unit testing. Integration test groups them in larger aggregates, applies tests defined in an Integration test plan to those aggregates, and delivers it as an integrated system that is ready for system testing.
System testing is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing is the first time that the entire system can be tested against the functional and non-functional requirement. System testing is intended to test up to and beyond the bounds defined in the software/hardware requirements specifications.
The acceptance test is jointly performed by users or sponsors with manufacturers or producers through black-box testing (that is, testers need not know anything about the internal workings of the system). The results will determine acceptance of the system. Acceptance tests generally take the form of a suite of tests designed to be executed on the completed system. Each individual test, known as a case, exercises a particular operating condition of the user's environment or feature of the system, and will result in a pass or fail Boolean outcome. The objective is to provide confidence that the delivered system meets the business requirements of both sponsors and users.
In order for testing procedures
Product Releasing (RITSOL_PD_Product_Release_Form_V1.2)
A software release refers to the creation and availability of a new version of a software product. Each time a software program has major changes, the project team should decide on how to distribute the changes or the changed system to the customer. Release procedure is a procedure concerned with the compilation, assembly and delivery of source code and any related documentation into finished products or other software components.
This is a list of assumptions that will be used during performing this process.
· The lack of early involvement of the software product engineering team in the software life cycle affects the efficiency of the planning, design and development decision. This may affect the quality of the final product.
· This process is implemented with others processes in the program, so the complete cycle has to be considered.
This is a set of risks which may impact the implementation of the process.
· Requirements gathering and elicitation are not planned.
· Suitable stakeholders are not involved in the elicitation phase.
· Requirements are not documented or well analyzed.
· Inexperience, lack of training of the requirements engineering team.
· Development team does not understand the user’s working environment.
· Difficulty in defining requirements; this could be attributed to inability of users to decide what they want, or difficulties related to the nature of the system.
· Requirements specifications are not well defined and not well validated.
· Requirements and their changes are not accepted by customer and senior management.
· High level and detailed designs are clearly defined.
· Tests are not well prepared and not executed in the required levels.
· Released products are not completely tracked and identified.
· The Project Management Process will plan, monitor, control and measure all activities in the Product Development Process.
· The Peer Review Process will provide a clear methodology for reviewing all critical artifacts during the performing of the process.
· The Quality Assurance Process will audit all critical process’s activities and work products.
· The Configuration Management Process will provide the infrastructure for performing all the activities. In addition, it will provide a consistent change management cycle for all changes.
- VSS (visual course safe) or other version control systems
- Database systems used for development
- Infrastructure support for development machines and tools
- Test beds infrastructure support