The fourth phase in the Software Development LifeCycle is the Requirements Phase. We have now finished the documents for the Initiation, Software Concept Development and Planning phases. Next, we write the technical documents to capture user requirements, business requirements and functional specifications.
Category Archives: Requirements Phase
Templates to document the functional, business, and technical requirements
A few weeks ago, we looked at Peer Reviews for Software Development LifeCycle projects. This week, we’re going to look at what you need to include when doing Peer Review for System Requirements Specifications. Reviewing System Requirements Specifications You can use the same free template we shared last time – email me if you don’t […]
If you’re looking for ways to write your first Functional Specifications Documents, then the following tutorial will help. One way to develop Functional Specifications is to use free Microsoft Word templates from the web and modify different chapters or buy professional template sets with pre-formatted samples. What are Functional Specifications Documents? Functional Specifications Documents (also […]
Functional requirements explain what has to be done, and identified. The necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the top-level functions for functional analysis. Functional Requirements Excel spreadsheet Performance Requirements The extent to which a mission or function must be executed; generally measured in terms of […]
Requirements are categorized in several ways. The following are common categorizations of requirements that relate to technical management. The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer. Operational requirements will define the basic need and, at a minimum, answer the questions […]
A software requirements specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software. Use cases are also known as functional requirements. Functional Requirements Excel spreadsheet In addition to use […]
A use case is a technique for documenting the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the […]
Prototypes are mock-ups of an application. Mock-ups allow users to visualize an application that hasn’t yet been constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built. Major improvements in communication between users […]
Best practices take the list of requirements merely as clues and repeatedly ask why until the business processes are defined. Stakeholders and developers can then devise tests to measure what level of each goal has been achieved. Goals change more slowly than the long list of specific but unmeasured requirements. Once a small set of […]
A major new emphasis in the 1990s was a focus on the identification of stakeholders. It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include: Organizations that integrate horizontally with the organization the analyst is designing the system for Back office systems or organizations Senior management […]
Requirements analysis includes three types of activity: Eliciting requirements: the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering. Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues. Recording requirements: Requirements may be documented in […]