During the inception phase the needs of the software are identi-fied, the requirements are elicited, risks are analyzed, and the acquisition processes are planned.
5.1.1 Acquisition proposal
The purpose of the acquisition proposal is to present the needs for and the feasibility of the acquisition, and also what benefits and risks exists so that an informed decision can be made by the sponsor on whether to initiate the acquisition project or not. In addition to the frameworks stated in appendix A, this artifact is based upon Pressman (1997).
Contents checklist
Describe the organization’s needs for the software prod-uct and how they are related to the organization’s objec-tives. What is the background of the needs? What is the current situation? What justifies the needs for the soft-ware?
Conceptualize the software product and give operational scenarios. What will the software have done?
What are the short-term and long-term consequences for acquiring the software? What are the advantages and drawbacks?
Analyze the alternatives for acquiring the software:
COTS, MOTS, internal development, outsourced devel-opment, joint venture develdevel-opment, enhancement of ex-isting software, or combinations of these alternatives.
What are the risks, costs, and benefits for each alterna-tive? Also do a market study of the alternatives.
Describe whether the benefits, short-term or long-term, outweigh the costs for acquiring the software?
Analyze the technical feasibility of the software. Are there any developmental risks? Can the necessary technical re-sources such as skilled staff and equipment be made available? Does the technology exist to develop the soft-ware or is it better to wait?
Determine any infringement, violation, or liability that could result from development of the system. Examine patents, copyrights, and other intellectual property rights.
Describe any external constraints on the project, such as standards, regulations, other projects, interfacing systems, etc.
Describe any public relations issues. Is there value in oth-ers knowing about this? How do we do that?
Describe how the project will be funded and give a time frame for the project.
State any priorities, assumptions, limitations, and trade-offs considered.
List potential contractors.
Give a motivated acquisition decision recommendation.
5.1.2 Project specification
The purpose of the project specification is to document the
deci-5 Artifacts
© Daniel Svennberg 2001 41
bounds, expected outcome, etc. which serves as a decision basis for the acquisition manager.
Contents checklist
Describe the organization’s needs.
Conceptualize the software product and give operational scenarios. What will the software have done?
Define the purpose of the project. State the acquisition project’s goal and vision in specific, measurable, accepted, realistic, and time-based terms. Specify the expected out-come of the project in terms of total cost, delivery time, product scope, and product quality, etc.
Specify the initially identified product requirements and their relative priorities.
Describe any identified risks.
Specify funding and time bounds.
Identify and give instructions regarding interfaces and collaborations with other projects.
Identify legal issues, such as intellectual property rights, etc.
Specify any external constraints, such as standards, regu-lations, interfacing systems, etc.
Give instructions on security, access to information, and confidentiality issues.
List potential contractors and/or capabilities that can be used for identifying potential contractors, such as re-quired competence, etc.
Describe routines for reporting project status. See the Project status report on page 56.
5.1.3 Acquisition plan
The purpose of the acquisition plan is to describe how the acqui-sition project will be managed.
Contents checklist
Describe the project’s background. Why is the project done? What is its purpose? State the project’s objectives.
State the project funding and schedule bounds.
Define the terminology that will be used in the acquisition project.
Describe what tools, techniques, and methods will be used.
Describe any standards, laws, practices, and conventions that are to be followed.
Determine problem resolution procedures.
Specify documentation requirements and procedures.
Specify configuration and change management proce-dures.
Describe collaborations and interfaces with external or-ganizations, support contractors, etc. and how the respon-sibilities are divided between the involved organizations.
Specify communication and reporting channels. List im-portant addresses, etc.
Determine acquisition project team inter-group coordina-tion and division of responsibilities.
Outline a master budget for the different processes.
Outline a master schedule describing the chosen acquisi-tion life cycle and appropriate milestones.
Specify security, access to information and confidentiality procedures.
Describe how public relations issues will be handled.
Describe routines for reporting project status
Describe how measurements will be collected, analyzed and used.
5 Artifacts
© Daniel Svennberg 2001 43
Plan each of the acquisition processes in chapter 6, Proc-esses, on page 60:
o Identify the process group members, their respec-tive responsibilities, and the organization of the group.
o Describe any collaborations and interfaces with other groups and organizations.
o Specify the scope and objectives of the process ac-tivities.
o Determine the working methods of the process group.
o Specify and schedule the process activities. Deter-mine who is responsible for each activity.
o Specify the budget for the process activities.
o Describe other resources allocated for the process activities in form of equipment, tools, materials, documents, facilities, etc.
o Determine how the process activities will be coordi-nated and how progress, problems, etc. will be re-ported and reviewed.
5.1.4 Risk list
The purpose of the risk list is to describe the identified risks, prioritize the risks and provide contingency and mitigation ap-proaches for each risk. The risk list should be maintained cur-rent and used as a tool for communicating risk issues between the involved parties. Each item on the risk list can contain sev-eral of the following:
Contents checklist
Risk identification.
Risk classification.
Date of last update.
Risk description, i.e. condition and consequences.
Probability of risk occurring.
Impact of risk occurrence.
Risk exposure, i.e. probability × impact.
Indicators of risk turning into a problem.
Approaches to control, transfer, avoid, minimize, and mitigate risk.
Name of person responsible for mitigation activities and date for last implementation of those activities.
Status of indicators and mitigation activities.
Contingency plan, what to do if the risk occurs.
Contingency triggers, what conditions are necessary for the contingency plan to be implemented.
5.1.5 Requirements specification
The purpose of the requirements specification is to capture and describe the requirements of the software product and other de-liverables. The requirements can be described several different ways such as shall-statements, problem statements, use cases, or user stories1. The contents checklist is partially based upon Kar and Bailey (1996).
Contents checklist
State the project goals. Which goal is the most important one in case a trade-off decision needs to be made?
Describe the software product in general terms; what is the background for acquiring the software, what is its us-age domain, what type of product is it, etc.
1 More information about requirements can be found in numerous web sites and books. See for instance “Managing Software Requirements: A Unified Approach” by Dean Leffingwell, Don Widrig, and Edward Your-don (ISBN 0201615932). Information on user stories can be found on:
5 Artifacts
© Daniel Svennberg 2001 45
Describe the different kinds of users the software will have. How do the different types of users use the soft-ware? What will the software have done for the user?
Are there any safety or security restrictions?
Describe the target hardware for the software.
Describe the external interfaces, to humans, hardware and other software.
Define the terminology used in the specification.
State any assumptions that have been made.
State the functional requirements. How shall the software handle the different types of input, and what output should it produce? How should errors be handled?
State the non-functional requirements, in terms of per-formance, portability, efficiency, reliability, usability, availability, and maintainability.
Verify and validate each requirement:
o Has the requirement been designated an identifica-tion for traceability purposes?
o What is the justification and motivation for the re-quirement?
o How will the fulfillment of the requirement be veri-fied?
o What other requirements is the requirement related to?
o Is the requirement necessary? Will a deficiency exist if the requirement is deleted?
o Is the requirement minimal or can it be divided into separate requirements?
o Does the requirement state what is required, and not how it should be met?
o Is the requirement attainable?
o Is the requirement complete or does it need further amplification?
o Is the requirement consistent with the other re-quirements in such that it doesn’t contradict any
other requirement, isn’t a duplicate of any other re-quirement and uses the same terminology as the other requirements?
o Is the requirement unambiguous?
o Is the requirement written without the use of vague words, such as “flexible” and “user friendly”?
o Is the requirement verifiable by inspection, analysis, demonstration, or test and is a verification criterion stated for each requirement?
Prioritize the requirements.
Describe what risks are connected with each requirement.
Give implementation time estimates for each requirement.
Verify and validate the total set of requirements:
o Is the total set of requirements complete, and doesn’t need any further amplification?
o Is the total set of requirements consistent, in such that no duplicate or contradictory requirements ex-ist, and the same terminology is used for all re-quirements?
State any installation requirements.
State any requirements regarding manuals and documen-tation.
5.1.6 Maintenance plan
The purpose of the maintenance plan is to describe how the sup-port and maintenance organization will be working.
Contents checklist
Identify the members of the support and maintenance or-ganization, their respective responsibilities, and how they are organized.
Describe any collaborations and interfaces with other groups and organizations.
5 Artifacts
© Daniel Svennberg 2001 47
Describe the resources allocated for maintenance activities in form of equipment, tools, material, documents, facili-ties, etc.
Specify allocated funding and budget for maintenance ac-tivities.
Determine maintenance scope and how the maintenance activities will be coordinated.
Describe procedures for problem and maintenance report-ing.
Describe how problem and modification analysis will be performed.
Describe procedures for modification implementations.
Describe how maintenance activities will be reviewed and accepted.
State migration and software retirement procedures.
State configuration management activities and proce-dures.
State the continuation of requirements management ac-tivities and procedures.
Specify what standards, methods, practices and conven-tions will be followed.