Precise Requirements (C) framework models requirement with these five components: user stories, business rules, screens, function models, and data models:
User Stories
A user story is a statement of functional requirements for an actor (user role) to achieve a business result. While specifying a user story, you need to identify the action and the actors. A user story can associate with one or more actors. The actors are parameters or context of action, and decoupling of actors from user stories make the functional specification more generic and reusable. In addition, you need to specify the intention of the action so as to make the user story meaningful and understandable.
To record and organize user stories, a perspective to look at is that a user story usually is part of a business process where requires user's involvement, and naturally, user stories can be partitioned by business processes. You can specify a feature for each user story so that it is organized into a feature hierarchy. Other than partition-by-process, a feature can represent other type of partitioning strategy whichever appropriate. The point is, use feature as a partitioning strategy for user stories.
Business Rules
User stories don't provide enough details for the development and the testing, they only represent the “what”, but not the “how”. Business rules (BR) provide the required level of details.
A BR is a piece of logic or condition advising how business activities (user stories) should be proceeded or restrained. With Precise Requirements (C), each BR specification contains references to one or more user stories where it is applicable. Business rules are about business activities, and each of them can be applied to one or more user stories. Precise Requirements (C) maintains business rules in a separate catalogue so that they can be reused by different user stories.
Examining business rule types is helpful for identifying and specifying them. Generally, a business rule can take following three basic types: how, extension, and constraints. A "how" BR provides the proceeding logic on a user story or on its subordinate activities; an “extension” BR defines a trigger in a user story under certain conditions; a “constraint” BR provides the conditions to restraint a user story or an action from proceeding.
Screens
A screen is to specify the user interface that the actor performs a user story, even though a user story can be performed by multiple actors on different screens. A screen usually accommodates many user stories to perform. Actions derived from business rules won’t have corresponding screens since they are subordinate activities of user stories, and they don't have user interface - they are realized in the function models as logical routines.
A screen is to specify the interaction process (the logical steps) between the actor and the system. it should address the intention of the interaction, including what to communicate, and the environment of interaction, e.g., touch screens or mouse clicks, handset or desktop and so on. Screen specifications should gather details that are required by the UI designer. When completed, screen specifications will also be a major part of the user manual.
Function Models
Function modules are the result of decomposition and organization of business capabilities. They sit in a joint layer where the user stories are realized through the support of data models. Structurally, a function model is a realization of a collection of user stories and their subordinate actions. Business processes are realized through leverage of function models.
Specifying function models is an endeavor of converting business activities into solutions. User stories and business rules are analysed and realized in multiple logical levels as it goes deeper into details.
Function models are identified based on business coherency and dependency among user stories and their subordinate actions. Intensive evaluation on business-wide cohesion and dependency is required for resulting in proper function models.
Data Models
Precise Requirements (c) data models serve as partitions of the conceptual space, each addressing a subject. Structurally, a data model comprises a main business entity and multiple affiliated or associated data entities. Data models provide the material and infrastructure that user stories are realized upon. Data models stand for the nouns in a solution, object-oriented, encapsulating data as well as the behaviours.