What is a Brief?
A brief can be defined as one of three things, depending on the profession in which it is being used. It is either:
A summary of facts, findings, and objectives intended to provide its reader a brief, high-level view of a plan, situation, or project.
A legal written statement, submitted to a court by each of the opposing parties in a legal dispute, setting forth the facts, laws, and precedents that support their respective cases.
A man’s or woman’s undergarment.
For our purposes, we’ll stick with the first definition.
Using briefs as the basis for agile documentation makes sense. A brief, by its very nature, is intended to provide just-enough information for its reader to get the job done. It is not a detailed and exhaustive representation of a project. This does not mean that a brief is an agile document. It may be used in both agile and non-agile settings.
Types of Briefs
There are different types of briefs that might be written during a project, but four, in particular, are fairly standard. Each has a specific purpose and may serve as a foundation for another. They are:
Business requirements brief (in certain instances)
Client brief
Creative or design brief
Project brief
Our focus for this course is, in fact, the client brief. So we won’t waste time talking about the other three, except to say that the business requirements brief does not apply to all projects, and the client brief is to blame.
Two Very Different Client Briefs
It’s important to note here that there are two distinct ways in which organizations might use client briefs. One does not make use of a business requirements brief, the other often does. This course is based upon the latter of these premises, as it is more applicable to the job of a software architect. However, to address any confusion that might arise about our use of client briefs here, let me explain the purposes of both types.
Prepared by the Client
The most common type of client brief is the one prepared by the client for an agency. This tends to be almost exclusively written as a marketing brief to solicit bids from creative/design agencies and does not typically use a business requirements brief.
In this usage, the client brief provides direction for the creative/design team. It may be applied to a forthcoming agile project, or direct the design team to NOT follow agile methodologies due to organizational requirements or other reasons.
If you are the client in this scenario, and you are shopping around for a suitable creative agency for your project, then you might create your client brief to request preliminary bids.
Prepared by the Project Manager
The other type of client brief is NOT typically produced by the client, but rather by the project manager for the client. The client may prepare a business requirements brief for the development agency, or the project manager may conduct interviews with the client to determine the requirements for the project. The project manager then prepares the client brief, which is a summary of the project the client has requested, and which is presented to the client for verification and approval. This provides the client with the assurance that the project manager understands exactly what is wanted and serves as a statement of what will be delivered.
Since this course is part of the Software Architect Path here at OpenClassrooms, it is more appropriate for us to discuss this type of client brief, and teach you how to write and present it to your client based on the information that is either provided by or extracted from the client.
Regardless of which type it is or who writes it, the client brief contains much of the same information. The difference comes in the form of marketing campaign direction versus business requirements.
We’ll discuss the contents of the client brief in detail in Part 2 of this course.
Briefs vs Software Requirements Specifications (SRS)
I keep reminding you that briefs are brief. Hopefully, you get the point. I mention it because a brief is the exact opposite of an SRS document. This type of artifact is a relic from the waterfall project management methodologies. It’s an expensive document to produce because it requires that the entire project be planned out in advance and exhaustive detail. The problem with this is that software projects rarely go exactly as planned. When changes happen, and the project begins to evolve, the entire SRS document has to be revised or rewritten, which typically means lengthy and expensive planning sessions to discuss the changes and the effects they will have on other areas of the project.
To give you an idea of how such a document can quickly become such an expensive problem, here’s a structural outline of a typical SRS document.
Purpose
Definitions and document conventions
Team contact information
References
Background
System overview
References
Project mission statement
Project introduction
Product vision and scope
Stakeholders
Business requirements
Overall description
Product perspective
System interfaces
User interfaces
Hardware interfaces
Software interfaces
Communication interfaces
Memory constraints
Design constraints
Operations
Site adaptation requirements
Product functions
User characteristics
Constraints, assumptions, and dependencies
Specific requirements
External interface requirements
Functional requirements
Classification of functional requirements
Functional partitioning
Functional description
Control description
Non-functional requirements
Performance requirements
Logical database requirements
Security requirements
Software system attributes
Reliability
Availability
Security
Maintainability
Portability
Environment characteristics
Hardware
Peripherals
People
Others...
Conclusion
Appendices
Use cases
Architectural diagrams
Data flow diagrams
State diagrams
Entity relationship diagrams
Others...
Can you see how a document like this could be very expensive to produce in terms of time and resources? It requires the project to be planned in its entirety and down to the finest detail before any design or development takes place.
Agile methodologies remove the SRS in favor of much shorter documents that contain just-enough information produced just-in-time for use. This pattern provides an effective medium for project and documentation evolution. When changes happen, only small documentation revisions are necessary, and subsequent documents are written with those changes already applied.
Let’s Recap!
A brief is a summary of facts, findings, and objectives intended to provide its reader with a brief, high-level view of a plan, situation, or project.
The four primary types of brief are:
Business requirements brief
Client brief
Creative or design brief
Project brief
The client brief, when used as part of an agile development project, is often written by the project manager and presented to the client for verification and approval. It provides:
A summary of the project the client has requested.
Assurance that the project manager understands exactly what is wanted.
A statement of what is to be delivered.
Now let’s summarize what you’ve learned in Part 1 of this course, after which you can check your understanding with the first quiz.
