Monthly Archives: May 2010

Requirements Analysis – Part 9 Functional Requirements

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 Analysis – Part 8 Types of Requirements

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 […]

7 Ways to Review User Guides

Post by Ivan Walsh. Follow me on Twitter. What can Kate Winslet teach you about proof-reading technical documents? Watch the movie The Reader and it will make sense. If she was writing this blog, she’d probably say: “Don’t do it all at once! One of the biggest mistakes you can make when revising any technical […]

Requirements Analysis – Part 7 Software Requirements Specification

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 […]

Requirements Analysis – Part 6 Use Cases

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 […]

Requirements Analysis – Part 5 Prototypes

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 […]

Requirements Analysis – Part 4 Measurable Goals

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 […]

Requirements Analysis – Part 3 Stakeholder Identification & Interviews

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 […]