All About Functional Requirements: Functional versus Non-functional Requirements

Functional Requirements, at one time, were very popular. They were included as part of the original Rational Unified Process (RUP) developed by a company called Rational Software Corp. When IBM acquired Rational Software (2002 / 2003) IBM removed the functional requirements from RUP. This approach created a communication gap between the stakeholders and the technical team implementing the requirements. Without the functional requirements inaccurate assumptions were made on both sides (i.e., stakeholders assumed developers were thinking like them; developers assumed stakeholders were thinking like them).

This post provides information on functional requirements including what a functional requirement is, how functional requirements are managed and the document (referred to as the Software Requirements Specification or SRS) used to describe functional requirements.

Functional Requirements Overview

A functional requirement is the lowest-level of software requirement among the software requirement types. It should not be confused with a non-functional requirement. Non-functional requirements do NOT convey software functionality, which is why they are called non-functional requirements.

A functional requirement states a single action that software can perform. However, unlike a use case, the functional requirement states a more specific system behavior or limitation as it pertains to user-to-system interaction or system-to-system interaction. The single action can be derived from a:

• Business rule the software must enforce or support; or,
• A system behavior stakeholders want the software to support or enforce (i.e., limit the number of characters that can be entered into a textbox, display a confirmation message when the cancel button is clicked, set the request to Submitted when the record is saved, etc.)

The functional requirement gives stakeholders more input regarding the software's behavior. And, functional requirements provide a way for Analysts to include lower-level system functional details that stakeholders can review and comment on. To use a functional requirement to enforce a business rule the Analyst can translate the business rule to one or more requirements.

Let's use an example where a stakeholder communicates the following business rule: All employee timesheets must be submitted by COB (Close of Business) on Friday. And, let's say we are building a Time Management System. Employees will use the Time Management System to add the following to their timesheets:  project name (i.e., US Gov Intranet), project task (i.e., Gather Requirements, Manage Requirements, Analyze Requirements, Design, etc.,) and hours spent on a task by date. The organization is building the Time Management System because the CIO wants to manage project costs associated with the number of hours employees spend on a project. Currently not all employees submit a timesheet by COB. With 150 employees on staff it's time-consuming for HR to figure out who didn't submit a timesheet.

We'll begin this portion of the project by adding "BR1. All employee timesheets must be submitted by COB (Close of Business) on Friday" to our requirements management system as a business rule. We have a use case named: UC3. Submit a Timesheet. We trace BR1 to UC3. And, UC3 is already traced to the following feature: FE1. Manage Project Task Hours & Approvals. FE1 includes all requirements that pertain to submitting and approving timesheets. (Note, additional information about tracing requirements is included in the Requirements & Traceability post.)

Translating Business Rules into Functional Requirements

The Time Management System cannot force every employee to submit his/her timesheet by COB Friday. But, the stakeholder wants us to define requirements so the System will enforce the business rule. We can use functional requirements to help the stakeholder achieve her objective, which is to ensure a timecard is submitted for every employee by COB Friday. Below is a list of requirements that will ensure the business rule is met:

1.  After 7:00 pm (EST) every Friday, the System shall access the online company calendar to identify every IT Department staff member out on vacation AND who did not submit a timesheet.
     1.1.    The system shall create a timesheet for every person on vacation who did not submit a timesheet.
     1.2.    The System shall record a 40-hour work week for each employee out on vacation for the week.
     1.3.    The System shall set the Project code to "Vacation – Paid time off."

2.  After creating timesheets for employees on vacation, the System shall create timesheets for all other employees who did not submit a timesheet.
     2.1.   The System shall record a 40-hour work week for each employee who did not submit a timesheet.
     2.2.   The System shall set the project code to "Miscellaneous – Unpaid time off."
     3.3.   The System shall automatically mark these timesheets as "not approved".

3.  The System shall send a notification to all employees for whom a timesheet is created.

4.  The system shall send a notification to the project manager associated with all employees for whom a timesheet was created and the timesheet was marked "not approved".

5.  The System shall send HR a list of all persons for whom a timesheet was created and the timesheet was marked "not approved"

Notice that each requirement states an action that can be performed using the software. And, lastly, notice the difference between a use case and a functional requirement. A functional requirement states a single specific action at a lower level than a use case.

Managing Functional Requirements

Functional requirements are added to the requirements management software just like use cases, features and business rules. In this example, IBM Rational RequisitePro is used to manage the functional requirements. The functional requirements are traced to use cases. In addition, a shorter name is assigned to the functional requirements to easily tell on functional requirement from the next. And, the letter ID used for the functional requirement is "FR".

Documenting Functional Requirements - the SRS

Functional requirements are added to the requirements management system and traced to the applicable use case. If the functional requirement is used to enforce or implement a business rule the functional requirement is traced to the same use case to which the business rule is traced. In this example, the functional requirements are traced to UC3. Submit a Timesheet . Tracing is what shows everyone on the team the relationship amongst requirements (see the Requirements & Traceability post).

While use cases are usually defined in a use case specification, functional requirements are typically added to the Software Requirements Specification (SRS). Or, an organization using the SDLC may add them to a different document. If creating the SRS, it usually includes a chapter called System Design. Under System Design is a heading that includes the Feature name. In this example, the second-level heading under System Design would be FE1. Manage Project Task Hours & Approvals. The third-level heading is the use case, which in this example is UC3. Submit a Timesheet.  The functional requirement is then added as the fourth-level heading. Following is a screen capture that shows a partial table of contents.

-------------------------

-------------------------

The functional requirements are added as headings to make document review easier for stakeholders. Notice a stakeholder can review the table of contents and choose what functional requirements he or she wishes to review in detail. This is particularly useful as requirements are changed and only select requirements must be reviewed.

Under the functional requirement heading the Priority is indicated along with the Stimulus/Response Sequences and the Requirement Details. The Stimulus/Response Sequences table defines the stimulus that starts the process for the functional requirement. Next, the response to the stimulus is added to the Response column. The stimulus/response details are added until the functional requirement is met. The Requirement Details section is used to add any additional information about the functional requirement. The following picture shows the sections under the functional requirement heading.

 -------------------------

  -------------------------

With functional requirements added, the test team or Systems Analyst would create not just a Test Case Specification but also a Test Procedure Specification. This approach ensures all of the requirements are tested for correct implementation

Functional Requirements versus Nonfunctional Requirements

While functional requirements define functionality associated with software; non-functional requirements are just the opposite. Non-functional requirements are requirements that do not add functionality to the software product. In other words, if you read a requirement that you CANNOT sit in front of a software application and perform--it is most likely a non-functional requirement.

Examples of non-functional requirements include requirements that outline the requirements for the technical documentation. Another example is training requirements for the end-user. System requirements are another type of non-functional requirements. System requirements state the minimum version of an operating system or minimum hardware requirements needed to run a software product. For example, a software product might require Windows XP or higher as the operating system. Notice in each example, it is not possible for a user or system to perform the stated requirements.  There are also non-functional requirements that define that allowed downtime for software maintenance and so on. Most non-functional requirements are added to the Supplementary Specification. Although some may be included in the Vision document and the Software Requirements Specification.

 

Final Thoughts

If you are defining use cases for a project you might consider using functional requirements. Functional requirements provide a way to add lower level details to a project. This aspect of detail becomes very important when developing complex business solutions. Remember each functional requirement should state a single action that a software product should support. And, functional requirements can have a parent and child relationship just like use cases. Typically, functional requirements that have a parent/child relationship convey that the child requirements have some level of dependency to implement the overall parent requirement.

Agile Manifesto, the Twelve Agile Principles

This post reviews the Twelve Agile Principles and provides some evaluation, opinions and additional information, from experience, about the Principles. In addition, where applicable, this post ties these Principles back to the relevant industry best practices.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Agile supports a continuous cycle of planning, requirements, design, development, testing and deployment by delivering agreed upon software (i.e., every couple weeks or months) using an incremental approach. Keep in mind prior to the requirements being implemented they should have been approved by the stakeholder(s). Once requirements are approved they should be assigned a release or sprint and completed as outlined in the project plan. In addition, the quality of the software and whether or not it contains the functionality asked for all play a role in the customer’s satisfaction. As I mentioned in an earlier post, you can give the customer quick turn-around times and even software with a savvy user interface. However, if the software doesn't provide the functionality the stakeholder needs; the stakeholder won't be satisfied. Lastly, using a software design that meets industry best practices also ties into customer satisfaction. Here are a few points to keep in mind:

• Add requirements to a tool that enables the Business Analyst (or Systems Analyst) to indicate whether a requirement is approved or not approved. User stories can and should be traced just like use cases so they are grouped by feature.

• For software to satisfy the customer it must be sufficiently tested. Testing should verify that the requirements are implemented as stated. And, testing should also verify that the software product works. In other words, does the software have defects that will make users complain and cause the primary stakeholders to, ultimately, be unhappy?
• The software design must be scalable and maintainable. This aspect of software is so important. I supported a project once where the software design for the reporting component of a business application was far more complicated than it should have been. Instead of using Crystal Reports or other similar reporting software the vendor wrote lines and lines of code that took months to complete. Needless to say, it was very difficult for the customer to maintain and update the software, which made the customer very dissatisfied.

 

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

This principle directly ties to the first principle. If a stakeholder voices a need for a requirement change; it is definitely up to the technical team to meet that need. Although, keep in mind, the technical team typically cannot tell the stakeholder whether or not a requested change provides a competitive advantage. And, a stakeholder may not stop to assess whether or not a change provides a competitive advantage. Most often, when a stakeholder wants a change implemented--it's implemented. Interestingly, over the years I have seen requirements change for many reasons. For example, I was hired by a company whose entire technology team told me the stakeholder couldn’t make up his mind. They said the requirements never made it to development. I met and talked with the stakeholder knowing the problem couldn't possibly be as bad as they said. I documented the requirements as he stated. Then I created the requirements document. The stakeholder reviewed the document. He then changed everything we had discussed.  We went through about four revisions of the document when I finally decided to try something different. Instead of continually rewriting the documents I decided to create UML (unified modeling language) diagrams, navigational flow diagrams and user interface (UI) mockups for the software product. I showed him the diagrams and the UI mockups. He made his changes on the diagrams and the mockups. I updated the diagrams and showed everything to him again. He approved them. I then used the diagrams and mockups to update the requirements documents. He signed off on the requirements documents and development began.  In this situation, the stakeholder was more of a visual learner and the text wasn't giving him the clarity he needed to make a firm decision. Lastly, if requirements are changing it is possible that the Business Analyst will need to generate an impact analysis report. The impact analysis report can then be used to see whether or not dates will need to shift because of the changing requirements. 

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

I supported a project where the Information Technology Department went through the entire cycle and completed a software product. During the walk-through (where the IT team showcased the system features) the IT team was told the software was not what was needed. Millions of dollars were just wasted building something the organization didn't need--all because the requirements were wrong. There is certainly value in implementing a business application using an incremental approach. Keep in mind that the team still performs the planning, requirements, design, development, testing and deployment. However, the team picks a much smaller scope of works for the Business Analyst to work on. Once the BA has completed the smaller scope of work that work is then passed on for design and so on. The BA then starts working on gathering requirements for the next scope of work. A continuous cycle is followed until the project is completed. By focusing on completing smaller scope of requirements, the team completes a smaller scope of work iteratively so the customer is continuously seeing updates to the product. These updates may be every two weeks or more; but should not be more than two months.

4. Business people and developers must work together daily throughout the project.

Depending on everyone’s workload this Principle may or may not be feasible. At a very large agency where everyone is very busy we met daily for about ten minutes. However, we only did this once development started. Project planning was limited to the people needed to plan the project including the technical team and the product owner. Requirements gathering sessions included the stakeholders and the technical team. The daily ten-minute status meetings were held once development started. The objectives of the daily 10-minute status meetings were to accomplish the following:

a.     Understand what issues technical team members were having,
b.     Understand what barriers needed to be removed, and
c.      Assign action items to those who could fix the stated problems.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Every decision most organizations make is done so with their overall business objectives in mind. For example, an organization has a Time Keeping System that three departments use for billing and cost management. The Time Keeping System supports business objective 3. Manage costs and implement projects within budget. On the other hand, everyone uses the corporate intranet to read the latest news about the company. The corporate intranet meets a lower business objective that aims to keep everyone informed. The organization will approve the Time Keeping System project. To execute this principle, the organization would look for its most highly motivated people. These are the people that always get things done with little or no prompting. They always meet their timelines. These people also initiate solving problems without being asked. If an organization seeks to build its projects around these types of people, the project will most certainly meeting its timelines.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Face-to-face is the best way to communicate because you can "see" if someone is puzzled or doesn’t understand a question. And, I've seen quieter individuals gain motivation to speak up from the more talkative participants. However, if face-to-face is not always feasible (because people live in different parts of the world or schedules are too hectic) meet face-to-face as often as you can. When it isn't feasible to have an in-person meeting there are two other approaches that can be used as follows:

• Microsoft Office Lync supports video conferencing, desktop sharing and chatting.
• Microsoft Office SharePoint 2013 includes an updated My Site component that delivers a much stronger collaboration experience to help teams work more closely together regardless of location or schedule. Microsoft Office 365 offers SharePoint Online, which can be less costly to implement than the non-cloud version of SharePoint.

7. Working software is the primary measure of progress.

It is a good practice not to get excited when the documents are written or the software is in testing. The real measure of progress is when the working software has been delivered. And, any release notes, training, user documents, etc. agreed upon are also delivered along with the working software. Again, the software should have been developed from stakeholder-approved requirements assigned to the release or sprint.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

For those of you who have ever implemented the complete Rational Unified Process (RUP), you probably can appreciate this Principle. Although, for some projects the complete RUP is needed because of the software project and the organization's business. For other software projects the complete RUP may be too much. If this is the case, the organization may implement a customized version of RUP, which I helped many organizations do. Or, the organization may benefit from a different Agile methodology that enables the project team to define and implement small scopes of functionality.  If the project does implement an Agile methodology the activities should not be so intense and the scope of work so big that it takes over two weeks (or two months) to complete. Instead, the activities should encourage the team to do exactly what is needed to complete the work accurately and remain within budget, timeframe and scope. This approach should enable the team to consistently complete a scope of work within the given timeframe. And, the team should always be able to deliver quality work because the work processes have been simplified as much as possible.

9.  Continuous attention to technical excellence and good design enhances agility.

A poorly designed software product is more difficult and costly to maintain than a software product with a good design. One of the most popular features of a good software design is reuse. Software reuse enables teams to accomplish more in a shorter period of time because code is reused. However, to reuse code takes planning from an organizational stand point. This is because code must be designed and developed properly for it to be reused. Many organizations are turning to using web services because developers can easily discover and reuse components. And, a web service can be shared across any platform. A second popular feature of good software design is usability. Microsoft says a software product has a good design if it is both simple and powerful. The article titled Power and Simple says an application is perfectly designed when there is the right balance of features and all unnecessary elements have been removed.(Microsoft's Simple and Powerful software design article can be accessed from the following link: http://msdn.microsoft.com/en-us/library/windows/desktop/aa511332.aspx)

10.  Simplicity--the art of maximizing the amount of work not done--is essential.

This Principle speaks for itself. Basically, use the simplest and most efficient way to complete the work that remains (after all, there is nothing you can do about work already completed). Most organizations looking to shorten the work cycle will most likely find a more practical way to perform project planning and requirements management (looking at ways to efficiently and effectively manage requirements without writing lengthy documents). Most organizations do not want to cut development or testing because of the inevitable consequences. Deployment is usually straight forward, if it pertains to a web application. Notifications are sent to the end users; the web application files are uploaded to the web server; and, the database is updated.

11.  The best architectures, requirements, and designs emerge from self-organizing teams.

The self-organizing team concept empowers people to do their jobs and make decisions about how they do their job. If you are a Business Analyst, for example, and the project manager is telling you how to gather requirements and manage them you are not part of a self-organizing team. The following link provides a great article on self-organizing teams: http://scrumalliance.org/articles/466-selforganizing-teams-what-and-how

 

12.   At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Ongoing self-improvement really should be every team member’s goal to become the best at what they do. A very effective concept used to help IT teams improve is called Lessons Learned. Through Lessons Learned sessions the team looks at its processes including what it did well and what it did not do well. The team also looks at areas in which it could have performed better. In addition, the team determines if the product met the stated requirements and if not, why not. And, the team assesses whether or not the customer was happy with the delivered product and if not, why not. These are just a few of the areas reviewed during a Lessons Learned session. Following is a useful link outlining best practices for Lessons Learned: Https://confluence.cornell.edu/display/CITPMO/Facilitation+of+Lessons+Learned+Discussions

Using SDLC Phases for Status Updates - IT Projects

With RequisitePro you can add SDLC Phases to improve the likelihood of a successful IT project through real-time status updates. This post provides information on RequisitePro attributes and it tells how to add the SDLC Phases and SDLC dates to make IT project management easier. It then provides a detailed overview of the Software (or System) Development Life Cycle, which is the overall processes used to conceive, plan, define, design, build, test and deploy a software application or business system.

In RequisitePro you can use pre-established attributes for each requirement type; or, you can add your own attributes. Attributes provide additional information about requirements so software developers do a better job of developing, testers do a better job of testing, analyst do a better job managing and IT project managers do a better job of monitoring. Below is what some of the the out-of-the-box use case attributes look like in IBM Rational RequisitePro.

Notice, at a glance, you can see the normal flow, alternate flows, includes, extends, etc. for each use case. If you configure RequisitePro to handle all of the attributes included in the Use Case Specification you can then distribute the printouts from RequisitePro instead of creating the Specification.This approach is useful if the IT project manager wants to reduce the time typically spent creating requirements documents. Also, if you look at the title for the RequisitePro view you will see it is called “Developer View”. This is because the Developer View contains the attributes that give the developer the same insight he would have if he were to view the use case specification.

Notice, in the picture below the user interface attribute has been added. In this scenario the images are stored on a web server and the URL to the image is included in the user interface field.The developer can use a web browser to view the mockup image and either store the image locally or continue to use the web browser.

By default, the use case attributes include the priority column. This ensures all requirements associated with a “High” priority are implemented before those associated with a “Medium” priority and so forth. In other words, using this RequisitePro view a software developer can look at the list and identify the requirements that must be implemented first (high), second (medium) and last (low).

The following picture shows additional attributes that can be associated with a requirement such as the SDLC Phase attribute and the SDLC date. These attributes are displayed on the Status Report view created specifically to convey the status of each requirement.

By adding the SDLC (Software or System Development Life Cycle) Phase to RequisitePro, the customer or IT project manager can look at the Status Report view to tell exactly what SDLC phase a requirement is in. In addition, the SDLC Date field defines the date the requirement entered the SDLC Phase. Notice, in the above picture you can tell what requirements are being tested, what requirements are in the design phase and what requirements are still in planning or the requirements analysis phase. The good thing about this view is an IT project manager can tell, at a glance, if certain deliverables will not be developed within the agreed upon time-frame. For example, if the due date for delivering the ability to "add a project" is to be implemented by June 30, 2013 and as of May 29, 2013 the requirement just entered the Requirements Analysis Phase the IT project manager can address the problem. In this scenario, the IT project manager can either renegotiate the deadline or request that everyone work longer hours to meet the timeline initially agreed upon. Lastly, in the above picture, the software being developed is called TMS (Time Management System). A column called TMS Release has also been added. This column allows us to assign a release to each use case (for the IT projects using an iterative approach).

Now, for those of us who like refreshers the following paragraphs include a brief overview of the phases that make up the SDLC. Note that the following phases may vary some across Federal Government agencies. But the overall concept remains the same (i.e., you must plan a project, define the requirements, design the software component(s), build the software components, test the software , deploy it so users have access, and then maintain it).

The following paragraphs present a more detailed view of the the SDLC Phases and it includes information on the objectives of the phases as well. Overall the artifacts developed depend largely on an organization’s implementation of the SDLC.

• Initiation Phase: During this phase the organization conceives a software idea that addresses a need or problem. The goals of this Phase are to establish project sponsorship, develop a concept proposal, assign a project manager to the project, identify a group that will serve as the planning team, and perform an initial analysis of the associated business process and improvement areas, which may include automating some process steps. The information gathered from this phase is used as a foundation to determine whether or not it is feasible to move on to the next phase.

• System Concept Development Phase: The primary objective of this phase is to identify the boundaries or scope of the project. If funding is needed, this is the phase in which it is requested. Additional activities associated with this phase include analyzing the business need, assessing the alternatives, identifying project risks, defining the roles and responsibilities of the planning team, developing the initial IT project plan with milestones, defining the project success criteria and writing a high-level statement on how the IT project will meet its success criteria.

• Planning Phase: The primary objective of the Planning Phase is to create all of the necessary project management plans so the project begins with a structured, implementable plan to increase the likelihood of success. During this phase the project organizational structure is defined (i.e., who fills what role and who reports to whom). In addition, a few of the IT project management plans created include the risk management plan, staffing plan, requirements management plan, communication plan, problem resolution plan, architecture plan, change management plan, configuration management plan, test plan, deployment plan, etc.

• Requirements Analysis Phase: The Requirements Analyst Phase is used to gather requirements, manage the requirements, write the requirements artifacts, analyze the requirements for gaps and ask the questions necessary to close gaps. If an iterative approach will be used, this phase will be repeated until all requirements have been gathered and added to the requirements management system. In addition, configuration management may be used to ensure the documentation is properly mapped to development releases and controlled releases ensure the promised software functionality is delivered in the proper release. With configuration management version control must be applied.

• Design Phase: The objective of this phase is to translate the requirements into an implementable design. UML diagrams may be used and/or a design document may be developed. The result should be requirements tied to objects and behaviors that the software development team can implement.

• Development Phase:  The core activities associated with this phase include coding the software components, performing unit tests and integrating the components to build a solution (partial or whole) that can move into testing. 

• Integration & Test Phase: This phase is used to perform all required testing to ensure the software works properly and contains the requested functionality. Testing may include user acceptance, functional, system transactional, regression, etc.

• Implementation Phase: During this phase, the team deploys the software so users can access it. Release notes are distributed to end users to inform them of any updates, known defects, etc. Also a communication is sent to end users informing them of the day/time the new/updated software will be available. If this is the first time users will access the software, the location or URL needed to access the software is also provided. Once the software is deployed, the IT project team may host a meeting to document lessons learned so future implementations will be more concise and correct.

• Operations & Maintenance Phase: Key activities performed during this Phase include change management and associated activities used to make changes to the software after it has been deployed to users. In addition, a Change Management plan should have been created during the project planning phase. This is the phase in which that plan is executed. If a help desk exists, it is usually the first tier to troubleshoot software problems. If the help desk (or Tier 1) is not able to resolve the problem, the ticket is escalated to the more seasoned analyst team (called Tier 2). If Tier 2 cannot resolve the problem, the ticket is escalated to Tier 3, which is the development team. Tickets solved at Tier 1 are far less costly than those solved at Tier 3. This is one key reason IT project teams try to release software with as few known defects as possible. Also, missing functionality is addressed during this Phase. An end user may submit a change request to ask for functionality not yet implemented. If this occurs a business analyst (or systems analyst) will talk with the end user and other persons, as necessary, to gather the requirements to be implemented.

• Disposition Phase: The Disposition phase provides structured activities that should be followed if a software or hardware component is outdated; or, for some other reason is no longer needed. There are procedures that should be followed to ensure any data is archived, destroyed or migrated to another system, as necessary.

Summary

In this post you learned that you can either use pre-existing attributes in RequisitePro; or, you can add your own attributes. We added the SDLC Phases and then we added the SDLC Date attribute to RequisitePro. As the requirements move through the SDLC, RequisitePro is updated to reflect the SDLC phase the requirement is in and the date in which the requirement entered that phase. This approach makes it easier to support IT project activities surrounding deliverables and timelines. In addition, a Release column can be added to RequisitePro so the requirements can be associated with a specific release to support iterative development activities.