Discussion questions?

1. What is a Functional Specification and why is it important in software development?
2. How do you go about creating a Functional Specification? Do’s and Do not’s.
3. What are the components of a Functional Specification? What should they include?
4. How do you ensure that the Functional Specification is kept up to date with changing customer requirements?
5. What challenges have you faced in creating Functional Specifications?
6. How do you test the Functional Specification to ensure it meets the customer’s requirements?
7. How do you ensure that the Functional Specification is communicated to the development team effectively?
8. Who should write functional specs? This guy say program managers, others say team comprised of UI,UX designers and developers.
9. are functional specifications part of contracts? Or do they function as a contract? If so, doesn’t using UI specs alone leave other functional requirements unaddressed? Or left for interpretation?
10. One of the recommendations to creating functional specs is to keep them as precise as possible, while also leaving some room for changes and adjustments. What kind of techniques can we use to allow for changes in the document? How can this be seen from a contractual point of view?
11. Functional Specs in an agile environment, what changes as opposed to the water fall methodology? best practices?
    1. Perhaps this where the 80/20 rule fits? Not sure..

~~Suppose you are a manager of a business looking to get an app or a software built for your business. As a future user of the software, You have a general idea of what that software should look like, what functionalities it should have and how it should perform. These requirements you have regarding the software are called functional requirements. ~~

In this article, we will see what functional specs are, their purpose, how they should be presented.

What are they?

Functional specifications or specs, are documents, typically describe what the end user will be able to do with the built system. They can be a full-fledged documents on their own or a part of a larger software requirement specification document. They are an essential tool for ensuring that software development projects meet the needs and expectations of stakeholders.

Their purpose:

Functional specifications are important because they help to:

• well defined scope of a project
• Ensure that all stakeholders have a common understanding of the desired outcome
• Provide a basis for design and development decisions
• Facilitate communication and collaboration between development teams and stakeholders
• Ensure that the final product meets the needs of the users

Components of functional specs

To create functional specifications, it is important to first gather requirements from stakeholders, including end-users, business analysts, and project managers. This information can be gathered through interviews, surveys, and other methods. Once the requirements have been gathered, they should be organized and prioritized, and a detailed description of each requirement should be created. This description should include information on the desired behavior, inputs, outputs, and any constraints or limitations.

Functional specs, should be complete, i.e. and consistent.

According to this book by Whil hentzen, a complete functional specs have two major components:

1. A requirement and
2. A Use case

A requirement is a statement of WHAT the system is required to do. These requirements need to be measurable and organized according to priority.

A use case can then be used to further describe the requirements described above and create a detailed description of HOW the user interacts with a system and how the system should respond to the user’s action.

Ideally, the functional design process maps the “what to do” of the Requirements Specification into the “how to do it” of the use cases. During this stage, the overall structure of the product is defined from a functional viewpoint. The functional design describes the logical system flow, data organization, system inputs and outputs, processing rules, and operational characteristics of the product from the user’s point of view. reference

How to present them

• Traditional Text and diagram based

The traditional approach used to prepare functional specifications is to specify each functional requirements that the system should provide using text and diagrams. This spec is writeen in a away that can be easily read and understood by the different stakeholders, unaided. It also takes the longest time to prepare.

• Graphic based approach

This approaches focuses more on the user experience. it typically include diagrams, flowcharts, and other visuals that illustrate how the GUI will look and function. The specs also provide detailed descriptions of the user interactions that will occur with the interface, such as what happens when a user clicks a button or selects an item from a menu. Graphical functional specs are used to ensure that the GUI meets user needs and works as expected

Written Functional Specs, yay or nay?

This Article, seems to agree with you

Reasons?

1. Functional specs force you to make the most important decisions when you have the least information

2. Functional specs lead to feature overload

3. Functional specs don’t let you evolve, change,and reassess

   What to do instead?

4. Write a one page story about what the app needs to do.If it takes more than a page to explain it, then it’s too complex

   *Reminds me of this quote: “A specification that will not fit on one page of 8.5x11 inch paper cannot be understood.” - Mark Ardis

5. Start building the UI this will replace the functional specs

6. Draw some quick and simple paper sketches. Then start coding it into html. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground that everyone can agree on.

This guy, on the other hand is opposed to this idea. He believes, for any project that require more than a weeks long commitment, not preparing functional specs is setting oneself up for failure.

Also this 4 part article raises good point on why we need to write functional specs and how to write them.