Chapter 7

Introduction to Building the Right Software

What's in this chapter?

  • Understanding the importance of engaging stakeholders throughout the software development process
  • Learning how Microsoft is extending its ALM toolset in this release to incorporate stakeholders
  • Discovering other ways of integrating stakeholder feedback with Team Foundation Server 2012

Every software development project begins with requirements. These requirements may be stated explicitly, such as the need for a payroll system to initiate direct deposits twice each month so that employees can get paid, taking into account the salary rate for each employee, minus any deductions for taxes and other withholdings. Or requirements may be more implicit, even abstract, such as the need for a video game to be fun and enjoyable.

In some software development projects, requirements are stated up front, before any code is written. In these software development projects, coding can only begin after the requirements have been finalized. This is traditionally referred to as a waterfall approach to building software. With a waterfall approach, the outputs from one phase of the development lifecycle flow into the inputs for the next phase (requirements flow into architectural design which flows into coding which flows into testing and so on).

With agile software development projects, there is an explicit recognition that requirements will likely change and evolve over time, even during the lifespan of a single software development project. Business opportunities present themselves, competition forces innovation, new regulations and compliance policies are introduced, and even the introduction of new technologies makes some requirements obsolete while enabling other solutions. Requirements can even evolve as your software users start to use early builds of your software; this may cause them to change their opinions about their original requirements, or could inspire entirely new requirements.

The Agile Manifesto (http://www.agilemanifesto.org) says this about software requirements:

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

Regardless of the software development approach you take, it is vital to understand the requirements you are attempting to fulfill with your software. Arguably, the only software mistake more expensive than a bug is that of building the wrong software in the first place. At least bugs can be fixed whereas building the wrong software may cause you to need to scrap the effort entirely. This is such a serious problem in the software industry that we have invented a unique term for it: shelfware. Software that is either too hard to implement or doesn't meet the necessary requirements is doomed to sit on the shelf unused.

So how do we ensure that we adequately understand the requirements our software must fulfill? How do we account for changes to those requirements over time? How should we prioritize the requirements that we work on? A big part of the answer is to engage early and often with your software development project's stakeholders.

Note
Neither this book, nor Microsoft's toolset, endorses one particular process—waterfall or agile—as the universal solution for software development projects. Every software development project is different. A waterfall approach may be well suited for building the software for a lunar lander or a back-end banking system because requirements can be expressed explicitly up front. But a waterfall approach is typically ill suited for managing the development of a social media website because the ever-changing preferences of your users and fierce competition can drive rapid changes to requirements. An agile approach is typically better suited for this type of software development project.
Many projects even employ an approach that blends waterfall and agile techniques. Dave West of Forrester commonly refers to this as waterscrumfall. Microsoft built Team Foundation Server and the accompanying ALM tools with this flexibility in mind, which enables teams to customize the tools even if that means blending seemingly competing processes.

Stakeholders

A stakeholder can be anybody outside of the development team who has a vested interest in the outcome of a software development project. For example, end-user of the software is certainly a stakeholder and is perhaps the first person who comes to mind when we think of stakeholders. Another stakeholder may be the person who is funding a particular project. After all, end users may want an application to have a key piece of functionality, but if the person paying for the project believes that it is too expensive to implement then that's important for the software development team to know before they start writing code. A lawyer may also be a stakeholder because some applications may need to undergo scrutiny to ensure that certain compliance and regulatory requirements are met. If you are in the business of selling software then your product's marketing team will likely have a seat at the table. You can probably think of other stakeholders for your software as well.

Whoever the stakeholders are for your project, they are a vital part of your extended development team. Stakeholders can play a role in some or all of the following activities:

  • Requirements elicitation—This is the process of gathering requirements from stakeholders through brainstorming, focus groups, role playing, prototyping, and other techniques designed to capture what a stakeholder may need your software to do today and in the future.
  • Requirements analysis—During the analysis phase, the software development team determines which, if any, requirements need additional detail from stakeholders. This is also the time to resolve any conflicting requirements that may have been introduced by different stakeholders.
  • Requirements validation—As the software development team begins to capture and analyze requirements, they often turn these requirements into written specifications, use case models, visual storyboards, or other such artifacts which attempt to capture what they heard from stakeholders during the requirements elicitation and analysis phases. This is an important point in time for stakeholders to provide feedback about the intended implementation.
  • Requirements prioritization—As requirements are defined, they need to be prioritized. This phase is less important for waterfall-based projects. But if your project's stakeholders are expecting incremental deliveries of software, such as in an agile project, then it is important to determine in which order requirements should be implemented.
  • Feedback—As working code begins to take shape, it may be possible to further refine requirements by asking stakeholders to use interim builds of your software and provide feedback. When this step is implemented early enough, it can help uncover disconnects between the stakeholder's expectations and the development team's implementation in time to affect that upcoming release milestone.

The phases described in the preceding list are typically referred to collectively as requirements management. Like other aspects of software development, requirements management is both an art and science, and it has been covered extensively by other books (both Dean Leffingwell and Karl Weigers have written great books on software requirements). For the purposes of this book, we are focusing on the tooling that is provided as part of Visual Studio for working with requirements. In this section, you learn about the new PowerPoint Storyboarding add-in, as well as the new Microsoft Feedback Client. In this chapter you also learn about a few of Microsoft's partners who offer complementary products in the requirements management space. In Chapter 11, you learn how Team Foundation Server enables teams to prioritize the order in which your team will implement requirements.

Note
Henry Ford is quoted as having said that if he would have asked customers what they wanted they would have replied, “A faster horse.” Instead, Ford invented the Model T, which ushered in the automobile era, rendering even the fastest horses obsolete. The implication is that customers don't always know what they want, so it's sometimes up to us as developers to deliver what they need before they realize they need it. But be careful not to be lured into a false conclusion that you no longer need to learn about your customers' wants and needs. The reality is that you may need to get to know your customers even better than they know themselves in order to map observed needs to solutions you can deliver.

Storyboarding

Storyboarding is a technique that was pioneered by the cartoon and film industry to help visualize sequences before the expensive process of filming or animating had begun. Because storyboards are composed of simple sketches, they are quick to create and easy to re-create if needed based on feedback, filming constraints, script changes, and so on. After the director is satisfied with the overall flow represented by the storyboard, the expensive processes of designing sets, configuring shots, filming, editing, and so on can begin.

Storyboards have since found their way into software user interface design. A series of storyboard panels could show the way in which a user interacts with a website when researching and ordering a new coffee table. The storyboard can then be shared with prospective users, market researchers, information architects, and other stakeholders and experts whose opinions help to shape the storyboard into the best possible design for the software development team to implement. The storyboard then becomes an artifact that the software development team can use to help plan their implementation.

With Visual Studio 2012, Microsoft has released a new tool for creating and sharing storyboards. This tool is known as the PowerPoint Storyboarding add-in, and, as the name implies, it is based on Microsoft PowerPoint. In Chapter 8 you learn about the capabilities of this tool and how to use it to quickly and cheaply iterate on user interface design with your project's stakeholders prior to writing a single line of code.

Capturing Stakeholder Feedback

Wouldn't it be great if we could talk to our stakeholders about what they want our software to do, go off for a few weeks to build it, and then give it to our stakeholders and smile while they congratulate us on building exactly what they wanted? Unfortunately this rarely happens in the software development world. The very nature of software development is highly complex. There are technical challenges to overcome; complex business rules and other requirements must be captured and implemented precisely; and different machine environments must be considered, such as which web browser the users prefer, what languages they speak, what accessibility constraints they have, and so on. And if all that isn't challenging enough, we have to account for the users' taste and style preferences. We have all been in this situation: You are demonstrating your software; it works flawlessly; everything is going well; and then somebody complains that they hate the font you chose for the user interface. It makes you wonder if Leonardo da Vinci ever received complaints about the frames his masterpieces went into.

But “the customer is always right,” and it is up to us as the software development team to listen to their feedback and respond to the best of our ability to create the best possible deliverables. The Agile Manifesto pays credence to this idea throughout, such as in the first principle:

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

Many agile teams even go so far as to treat the customer as an integral part of the software development team. An end user or other stakeholder may attend weekly progress reviews or even participate in discussions about possible implementations. When this type of face-to-face interaction is possible, it can be invaluable for ensuring that the vision of the software development team is closely aligned with that of the stakeholders. But how can you achieve this type of cooperation when your stakeholders are geographically disbursed, time shifted, or too numerous to practically incorporate into the regular cadence of development team meetings?

Note
The term customer from the Agile Manifesto is synonymous with the earlier discussion of the term stakeholder. Stakeholder is sometimes preferred to customer because the latter implies an exchange of goods or services for money, whereas the former recognizes that money isn't always an underlying consideration when defining a person's interest or involvement in a project's outcome.

Microsoft has introduced another new tool with Visual Studio 2012 designed to facilitate this type of interaction. The Microsoft Feedback Client captures rich data about the interactions of a stakeholder with your software, as well as their reactions. The development team can start by initiating a request for a stakeholder to provide feedback about a user story or requirement that has been implemented. The stakeholder can then run the Microsoft Feedback Client while they are using the interim build of your software. Along the way, that stakeholder can choose to capture video and audio recordings, notes, and screenshots that reflect things that they like or dislike about your software. All of this data is centrally stored in Team Foundation Server so that the development team can analyze and react to it. You learn how to use the Microsoft Feedback Client in Chapter 9.

Work Item Only View

Another way of collecting input from your stakeholders is by allowing them to file bugs or enhancement requests directly to Team Foundation Server. This centralizes feedback in one repository that the development team can then react to and track over time. Microsoft does this for a wide range of Microsoft products via their Microsoft Connect website (http://connect.microsoft.com). Product groups at Microsoft synchronize data from Connect directly into their own Team Foundation Server work item databases, and any responses about the customer's request are returned to the user via the public website.

You can use Team Foundation Server for this purpose as well. But for most organizations, obtaining a Team Foundation Server client access license (CAL) for every possible stakeholder can be cost prohibitive. In recognition of this, Microsoft created a licensing exemption for stakeholders who may file bugs or enhancement requests. From the Visual Studio licensing whitepaper:

A user does not need a CAL or External Connector License to create new work items or to update work items that that same user has created. This exception applies only to work items related to defect filing or enhancement requests. However, a CAL is required when a user views or modifies a work item created by another user or interacts with Team Foundation Server in any other way.

Note
The latest version of the Visual Studio Licensing Whitepaper can be found at http://www.microsoft.com/visualstudio/licensing. This whitepaper attempts to synthesize all of the licensing requirements for Visual Studio, Team Foundation Server, and related technologies into an easy-to-read format.

Because stakeholders are not likely to have Visual Studio installed, the most common way of asking stakeholders to provide feedback in this manner is via Team Web Access, which is covered in Chapter 2. Stakeholders who don't already have access to Team Foundation Server can be added to the Work Item Only View License Group in Team Foundation Server. Users who are a member of this group are only permitted to create and update work items they create, per the terms of the aforementioned licensing clause. If a stakeholder requires more comprehensive access to Team Foundation Server they need to be licensed and permissioned appropriately.

Note
Detailed steps for adding users to the Work Item Only View License Group can be found at http://aka.ms/WIOV.

Third-Party Requirements Management Solutions

There are a number of approaches and solutions to requirements management and stakeholder engagement employed by software development teams. Although Microsoft has made forays into requirements management with the Visual Studio 2012 release by introducing the aforementioned tools, it continues to rely on tis broad ecosystem of partners to provide complementary requirements management solutions that integrate with Team Foundation Server. Three popular examples of these partner solutions are covered next. For information on other third-party requirements management solutions that integrate with Team Foundation Server, please visit http://aka.ms/TFSRequirementsPartners.

TeamSpec

One of the most widely used requirements management “tools” on the planet is Microsoft Word. Microsoft Word is popular, easy to use, and facilitates sharing and collaboration via tracked changes and comments. It's no wonder then that many software requirements live their lives as specifications in Word documents. TeamSolutions, a Microsoft partner, recognized the popularity of Microsoft Word in the requirements management space and saw an opportunity to keep requirements documents relevant by integrating Word and Team Foundation Server. They created a solution called TeamSpec to bring Microsoft Word-based requirements into a company's ALM process, and it has become popular among teams who use Team Foundation Server.

TeamSpec, shown in Figure 7.1, maintains a link between requirements in your document and pertinent work items in Team Foundation Server. One feature enables teams to compose requirements using customizable templates in Microsoft Word. The templates define fields that represent the elements of the requirement that will be mapped to Team Foundation Server. For example, the template for a user story may define fields for a title, a description, and the person on the development team responsible for that user story. The requirement document in Word can then be shared with project stakeholders for validation. The stakeholders can make proposed edits or comments to send it back to the development team just like they would with any other Word document. Then after the stakeholders have signed off on a requirement document it can be synchronized with Team Foundation Server as a work item or group of work items. TeamSpec is responsible for providing this synchronization by examining the contents of each field in the document template and pushing it into a corresponding work item field.

Figure 7.1

7.1

Another capability of TeamSpec is that it can be used in the other direction to generate Word documents from work items in Team Foundation Server. This feature is especially useful when the software development team has made changes to a requirement that must be communicated to the stakeholders. In this way, TeamSpec recognizes that requirements often evolve over time and that keeping the requirements in-sync, for all stakeholders, is imperative. You can learn more about TeamSpec at http://www.teamsystemsolutions.com/.

TeamLook

Another popular stakeholder collaboration tool, also from TeamSolutions, is TeamLook. TeamLook, shown in Figure 7.2, integrates work items from Team Foundation Server directly into Microsoft Outlook. TeamLook makes it easy to turn e-mails into work items, such as e-mails from a customer who may e-mail a bug or enhancement request that you want to capture in Team Foundation Server for the development team to triage and react to. Conversely, you can use TeamLook to generate e-mails from work items in Team Foundation Server—such as to provide the latest status of an enhancement-request work item to an important customer.

Figure 7.2

7.2

TeamSolutions also produces a related free tool called TeamBox, which is an automated e-mail service that converts any e-mail it receives into Team Foundation Server work items. Hence, you could configure

[email protected] to automatically create bug work items for the development team to triage. You can learn more about TeamLook and TeamBox at http://www.teamsystemsolutions.com/.

inteGREAT

inteGREAT, by eDevTECH (http://www.edevtech.com) is a requirements lifecycle management platform that integrates bidirectionally with Team Foundation Server 2012, with Team Foundation Server providing the centralized application and database store for inteGREAT.

inteGREAT, shown in Figure 7.3, enables users to elicit, analyze, validate, review, and manage requirements. inteGREAT also offers bidirectional integration with Microsoft Excel and Word, allowing business users to author requirements in tools that are familiar to them. It embeds Visio controls within the tool to facilitate the creation of many types of diagrams. It also integrates with Microsoft Project, publishes documents and an HTML knowledgebase to SharePoint and produces XAML code from its screen mock-up functionality. It even integrates third-party solutions such as CA ERwin and HP Quality Center.

Figure 7.3

7.3

If you are seeking a requirements definition and management solution that allows you to baseline projects and provides a more formal and comprehensive approach than that currently offered by Microsoft or Team Solutions, then you should consider evaluating inteGREAT.

Summary

In this chapter, you learned about the importance of engaging early and frequently with your software development project's stakeholders. During this process you capture, analyze, and validate the requirements your software needs to implement before you begin coding. Then, as your software evolves, you learned about getting additional feedback from stakeholders, which can influence the ongoing implementation to ensure that the development team is building the right software. Microsoft and its partners have built several tools to facilitate requirements management and collaboration with your project's stakeholders. These tools integrate with Team Foundation Server alongside the rest of your software development project's artifacts.

In Chapter 8 you learn more about the PowerPoint Storyboarding add-in that Microsoft has introduced with Visual Studio 2012.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.15.34.39