Project Requirements Definition (PRD)

After reviewing the initial client meetings, we recommend investing the time and effort into defining and documenting the requirements with a greater level of detail so you understand the full scope of the project, and the amount of time/effort needed. 

Areas to Be Defined

The following list represents sections needing further requirements definition.
NOTE: The list is not final and is not limited to the points below. As this process unfolds, additional items may be added to this list as needed, based on joint discussion and the required scope.

• Fully understand existing systems
• Review workflow/business rules of all requirements
• Review alternative implementation strategies for requirements
• Define and review backend/admin interface

Questionnaires/Interviews/Meetings

• Identify key contacts representing each of the sections requiring further definition:
  • Project Manager
  • Sample Target Audience (if required at this stage)
  • IT correspondents
  • Define other stakeholders
• Run sample demos
• Engage in discussion with designated points of contact,
• Assessment and review to cover any remaining gaps
• Analysis and Requirements Documentation
• Analyze findings
• Document alternative implementation strategies and detailed requirements
• Present recommendations

Based on the above process, we can create a fixed price proposal for delivering a solution on-time, within identified scope.

Use Case Modeling:

In software development, a use case is a method for capturing functional requirements. According to Bittner and Spence, "Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful"

Each use case provides one or more scenarios that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by business analysts and end users.

Scope and goals of a use case

Each use case focuses on describing how to achieve a goal or task. For most software projects this means that multiple, perhaps dozens, of use cases are needed to embrace the scope of the new system. The degree of formality of a particular software project and the stage of the project will influence the level of detail required in each use case.

A use case defines the interactions between external actors and the system under consideration to accomplish a goal. An actor is a role that a person or thing plays when interacting with the system. The same person using the system may be represented as two different actors because they are playing different roles. For example, "Joe" could be playing the role of a Customer when using an Automated Teller Machine to Withdraw Cash, or playing the role of a Bank Teller when using the system to Restock the Cash Drawer.

Use cases treat the system as a black box, and the interactions with the system, including system responses, are perceived as from outside the system. This is a deliberate policy, because it forces the author to focus on what the system must do, not how it is to be done, and avoids the trap of making assumptions about how this functionality will be accomplished.

Use cases may be described at the abstract level (business use case, sometimes called essential use case), or at the system level (system use case). The differences between these is the scope.