Skip repetitive navigation links.
United States Department of AgricultureFarm Services AgencySystem Development Life Cycle (SDLC)
Go to SDLC Home Go to SDLC Home Go to About SDLC Go to News Go to Help Go to Contact Us
Search FSA
Go To Advanced Search
Go To Search Tips
FSA Enterprise Architecture
Go to EA Overview
Go to Enterprise Architecture Program
Go to Enterprise Architecture
Go to FSA Infrastructure
Go to SDLC Overview
Go to Background
Go to Development Process
Go to Quick Start Guide
Go to FSA Quality Assurance & Control Process
Go to Project Management Process
Go to Configuration and Change Management
Mainframe & System 36 SDLC
Browse by Subject
Go to Developer Tools Overview
Go to Architectural Decisions/Waivers
Go to FSA Assets and Shared Services
Go to Approved Software
Go to Templates and Documents
Go to Information Bulletins & Memos
Browse by Subject
Go to Learning Overview
Go to Training Schedule
Development Process

Requirements & Analysis Phase



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

What To Do

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:

  • DBMO
  • 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.

Database Management Office (DBMO)

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.

Certification & Accreditation (C&A)

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.

Records Management

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.

Core Artifacts:

Business Process Model
Use Cases / User Stories

Optional or Supporting Artifacts:

Use Case Model


Last Modified: 06/29/15 11:11:46 AM

SDLC Home | FSA Home | | Common Questions | Site Map | Policies and Links
FOIA | Accessibility Statement | Privacy Policy | Nondiscrimination Statement | Information Quality | | White House