• 8 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 01/11/2023

What’s so Great About Briefs?

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:

  1. A summary of facts, findings, and objectives intended to provide its reader a brief, high-level view of a plan, situation, or project.

  2. 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.

  3. 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.

  1. Purpose

    1. Definitions and document conventions

    2. Team contact information

    3. References

    4. Background

    5. System overview

    6. References

  2. Project mission statement

    1. Project introduction

    2. Product vision and scope

    3. Stakeholders

    4. Business requirements

  3. Overall description

    1. Product perspective

      1. System interfaces

      2. User interfaces

      3. Hardware interfaces

      4. Software interfaces

      5. Communication interfaces

      6. Memory constraints

    2. Design constraints

      1. Operations

      2. Site adaptation requirements

    3. Product functions

    4. User characteristics

    5. Constraints, assumptions, and dependencies

  4. Specific requirements

    1. External interface requirements

    2. Functional requirements

      1. Classification of functional requirements

      2. Functional partitioning

      3. Functional description

      4. Control description

    3. Non-functional requirements

    4. Performance requirements

    5. Logical database requirements

    6. Security requirements

    7. Software system attributes

      1. Reliability

      2. Availability

      3. Security

      4. Maintainability

      5. Portability

    8. Environment characteristics

      1. Hardware

      2. Peripherals

      3. People

    9. Others...

  5. Conclusion

  6. Appendices

    1. Use cases

    2. Architectural diagrams

    3. Data flow diagrams

    4. State diagrams

    5. Entity relationship diagrams

    6. 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.

Exemple de certificat de réussite
Exemple de certificat de réussite