The Requirements & Analysis phase focuses on what the system will do in an effort that views all stakeholders, including sponsors and potential users, as important sources of information. During this phase you will:
- Create one unambiguous set of requirements that establishes an agreement between all stakeholders on what the system should do
- Provide developers and all other stakeholders with a clear understanding of the requirements
- Define the boundaries of the system
- Prioritize features to provide a basis for possible iterations
When in the Requirements & Analysis phase, a considerable amount of time will be spent interacting with stakeholders and reviewing the input they provide. The task of identifying stakeholders is crucial to help ensure all requirements are understood. Common stakeholders for all projects include:
- Information Security Office (ISO)
Once stakeholders have been identified, a Kickoff meeting should be held to ensure everyone is starting on the same page, and to help establish communication channels between the necessary groups. As soon as this occurs the gathering and analysis of the requirements can begin in full. Keep in mind though, that more stakeholders may be identified as the process moves forward.
There are a variety of techniques that can be used to gather the requirements, but some key points to remember are that the requirements must be systematic, verifiable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
Requirements analysis can be broken down into two distinct activities: capturing requirements and analyzing requirements. Capturing requirements is the task of communicating with stakeholders to determine what the requirements are. This is commonly done via formal and informal meetings, e-mails and phone calls. Analyzing requirements is the tasks of using standard tools and practices to generate a single unambiguous baseline of the requirements. Once all the stakeholders agree on the requirements, the baseline is created and becomes the formal requirements source. Below are the practices defined by the FSA SDLC for requirements analysis:
- Establish a Vision - Focus on the capabilities needed by the stakeholders and why these needs exist. Pay special attention to "what" the project should accomplish not "how" it should accomplish it. The Vision should also include the scope, features and environment of the project, as well as the precedence and priority of the features.
- Discover Constraints - Sources could include standards, mandates, directives, quality attributes, the environment, security and licensing requirements.
- Define Behavior - Identify the behavior the system needs to exhibit to provide the capabilities requested by the stakeholders. Common practices include Use Case Modeling and Business Process Modeling.
Interaction with the DBMO will likely occur during every phase of the SDLC. During this phase the interaction will primarily focus on establishing the communication channel between the development team and DBMO. This may include discussions of the basic requirements for the project and the identification of DBMO's degree of involvement as a stakeholder.
C&A documentation to consider during this phase: System Information Sheet, System Security Categorization Document, Privacy Impact Assessment.
Contact the Information Security Office
for further details regarding specific efforts relevant to this phase of the SDLC.
During the Requirements and Analysis phase the development team, with assistance from the records management team, should identify all records that support the business process. The development team will determine if the identified records have an existing schedule or if a new records schedule is required. For more information visit the FSA Records Management Web Site