Software Requirements

Unless you are purely a hobbyist or a student, software projects are undertaken because an organization needs the software to increase productivity of workers or to perform a task that cannot be done economically by a human worker.

The software engineering team must understand what the customer wants out of the software, so that they know what to build.

"The hardest part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements... No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later."

"Therefore the most important function that software builders do for their clients is the iterative extraction and refinement of the product requirements. For the truth is, the clients do not know what they want. They usually do not know what questions must be answered, and they almost never have thought of the problem in the detail that must be specified."

Brooks, Fred P. (1986). "No Silver Bullet - Essence and Accident in Software Engineering." Proceedings of the IFIP Tenth World Computing Conference: 1069-1076.

A condition or capability needed by a customer to solve a problem or achieve an objective, or needed to satisfy a contract or other formal document.

There are functional and nonfunctional requirements. What do you think the distinction is?

Functional requirement: What the customer wants the software to do.

Nonfunctional requirement: Places constraints on how the software meets requirements.

Study of the issues surrounding software requirements could be the content of a semester long course, a dissertation, or a book.

There are many different software development methodologies, with proponents of particular methods often (bitterly) disagreeing with each other on the subject.

Each software development methodology has its own style of handling software requirements.

I can, however, briefly give you my opinion on the subject of methodologies. They are situationally dependent. For certain projects, methodology A can have great success, for other projects the best choice might be methodology B. Some methodologies that would be ideal cannot be implemented due to external factors, such as contracts.

So, it is good to read up on or experience many from the following list:

Use Case: A description of important interactions between an actor (usually a person) and the software system. These interactions must yield a result of value to the actor. Sometimes diagrams are used to illustrate a use case, but these are rarely sufficient.

Use cases are a primary means of discovering requirements.

• Elicitation
• Analysis
• Specification
• Validation
• Management

Elicitation: Uncovering customer needs and wants and nonfunctional requirements.

Multiple sources of information can be used.

• Stakeholder Needs - They may have overlapping or disjoint sets of needs.
• Stakeholder Goals - How do the stakeholders see the software benefiting the organization?
• Domain Knowledge - What is common business practice in this industry?
• Operation and organizational environment - Is there consistency or conflicts?

How might you elicit requirements?

Multiple techniques can be used for elicitation.

• Interviews - 1v1
• Facilitated meetings - groups
• Observation - of how proposed users currently perform tasks to be handled by the software
• Scenarios - Software developers describing sets of use cases to the customer. This can identify misperceptions early on and uncover new requirements.

These techniques require skill and experience. This is a different skill set from writing functioning code!

Analysis: The study of requirements to determine if a system can be built from them.

The study can identify flaws in the set of requirements. What type of flaws could exist?

Common flaws include requirements that:

• contradict
• are incomplete
• are vague
• are obviously wrong

Specification: The formal capture of the requirements into a properly formatted document.

Requirements must be:

• Specific - clear, concise and exclusive
• Correct - must accurately describe the system function
• Complete - must describe everything about the system
• Consistent - non-contradictory or not-exclusive of other requirements
• Attainable - possible for software to meet this goal
• Verifiable - can we test that the requirement has been met?

Validation: An agreement by the customers that the requirements meet their needs.

This is typically accomplished by the customer reading and agreeing to the specification.

Management.

Why would you need to manage requirements after the specification is validated by the customer?

Two of the many good reasons.

Because requirements can CHANGE during a project! When changes to requirements occur, this can necessitate changes to other requirements and code already written.

Because the completion of requirements must be accounted for and tested before the project is delivered. One or more members of the development team must verify that all requirements are completed and tested.

A successful project will have one or more subject matter experts on the entire set of requirements.

The class is broken up into four teams.

Each team has been invited to compete to work on a software project for "General Science", a science magazine/website.

The invitation describes that the software will automatically generate webpages, e-mails, and/or text messages for a marketing campaign.

Each team will elicit software requirements, analyze them and draft a specification.

Each instructor will role-play a stakeholder and can be interviewed by each team seperately for 10 minutes.

The team that creates the best specification wins the contract.

The following "General Science" stakeholders are available for an interview.

• Chief Executive Officer
• Director of Marketing
• Jr. Science Editor
• Information Technology Director

Deliverable: Proposal describing approach. Ensure that software requirements as understood are addressed in proposal.

Recommendations:

• Elicit requirements from stakeholders using guidance from slide(s).
• Organize software functions around use cases.
• Seperate requirements into functional and non-functional.
• Look for contradictions and obviously wrong requirements.