Pattern: Requirements Specifications Shared only via Email

Pattern: When the stakeholders do not have access to the requirements repository the RA will collaborate on the specification with them via email.

Observations:

The RA was the only person with access to the requirements repository for smaller scale projects or when the infrastructure does not support stakeholder access. Surprisingly, it didn’t matter if stakeholders were members of the RAs organization or not, the system infrastructure appeared to be a prime factor affecting the stakeholders’ access to the project repository, if one existed. Table 5.9 contains the projects where the RA discussed their email process.

Project 1’s RA created and maintained the requirement specifications in MS word. The specs were then stored on a public drive within the RA’s organization, and emailed to external stakeholders for their review. Meanwhile the requirements documentation for Project 3 was drafted in MS Word, with imbedded Visio diagrams, spreadsheets and PowerPoint, and kept up to date by the RA and other members his consulting team. Project 3’s RA would share these specifications with their stakeholder/customers by either emailing a copy of the specs or a link for downloading the specs.

According to Project 4’s RA, SharePoint was their document storage mechanism. Because English was not the first language of many of the stakeholders, “We tried to make our requirements documents as

graphical as possible. But we also had detailed use cases and things like that in the documents along with very detailed requirements statements…” The process for creating and maintaining the requirements

specification was as follows: an RA would draft a document and then email it one-to the librarian for safekeeping, and two-to the necessary stakeholders for their review and approval. The librarian who was located in the U.S., “because we were so distributed amongst so many physical locations”, was responsible for loading the documents into SharePoint. After reviewing, the stakeholders would reply to the RA. The RA would then make the necessary modifications and update the version number before emailing the revised artifacts to the librarian.

Project 6’s RA developed the requirements documentation in MS Word; while Use Cases were created using Visio. Prototypes were an appendix to the Use Cases and Wire Frames illustrating main and alternate scenarios would follow the use cases. The requirements specification was emailed to the users for their review. Per the RA, “In most cases I would get <documentation updates> through email. So <the stakeholders> would either put their comments in the body of the email message without an attachment of

their markups; or I would get an attachment with their markups embedded and I would have to go through the document; and then I would integrate these comments and of course you run into situations where there’s maybe discrepancies or something’s not clear. You have to negotiate those different things together.” The use cases were also shared via email. As the RA explained, “Well unfortunately at the time that we did this, I had to email <the use cases> since we didn’t have a Wiki, and then our business users didn’t all have access to ClearCase which would have been the alternative way, to have a draft folder for working documents that they could just access that way. So we just had to email them.” The RA also

shared that this difficulty in sharing the use cases was one of the reasons that his department later created a project wiki.

For Project 10 requirement specifications consisted of MS Word documents, spreadsheets, and user interface and use case diagrams that were created by the RA. The documentation was shared with the stakeholders via email. Next the stakeholders provided feedback by noting corrections on a copy of the relevant artifact and returning it back to the RA, who then updated the master copy. When asked if it was difficult using email to keep track of the specifications, the RA replied, “not really. It may have worked

out a little bit better if it went directly into a tool for tracking, a database for tracking. But since the project wasn’t that complicated it was easy enough to look the information up in email. I could see if that got to be a huge project that it would definitely be an issue.” The artifacts were stored and maintained in

the RA’s own email folder. The RA continued, “And of course I copied pretty much the world for almost

everything. That’s another reason why it would’ve been better for it to be in one repository and one database if it was a larger project. Rather than having it proliferated all over the network for our business.”

Chapter 5. RE Modeling Research Sessions Data Analysis 96

Project No.

Industry Locations and Roles Stakeholder access to

Repository 1 Financial Services USA0 – RA

USA1 – 1 LSP + 2 Stakeholders No 2 Telecommunications USA0 – 1 RA USA1 – 3 Stakeholders USA2 – 2 Stakeholders Yes 3 Software Requirements Consulting Asia1 – RA + 1 LSP + 29 Stakeholders Europe1 – 2 Stakeholders USA1 – 4 Stakeholders USA2 – 3 Stakeholders No 4 Software Requirements Consulting USA0 – Project RA USA1 – 15 Stakeholders USA2 – 20 Stakeholders

Asia1 – Site RA/LSP + 30 Stakeholders

No

6 Retail USA 1 – RA + 2 Stakeholders

USA2 – 1 LSP + 5 Stakeholders No 7 Software Engineering Research Europe0 – 3 RAs Europe1 – 5 Stakeholders Europe2 – 5 Stakeholders Europe3 – 5 Stakeholders Europe4 – 5 Stakeholders Europe5 – 5 Stakeholders Yes

8 Corporate Research USA0 – RA + 6 Stakeholders USA1A – 3 Stakeholders USA1B – 2 LSPs + 23 Stakeholders Europe1 – 1 LSP + 4 Stakeholders Yes 10 Securities Software Solutions Integrators USA0 – RA + 3 Stakeholders USA1 – 3 LSPs + 100 Stakeholders USA2 – 4 Stakeholders No

Recommendations:

Our observations concur with Mittleman et al as described in Section 5.3.4 Requirements Engineering Tools and Technologies Pattern that email can be an effective tool. Much like the telephone in Section 5.3.2 Telephone - RA’s Preferred Communication Tool; stakeholder collaboration via email can be sufficient, especially if it is not a large project, for example Projects 1, 6 and 10 were comprised of twelve, fifty and thirty requirements, respectively.

Chapter 5. RE Modeling Research Sessions Data Analysis 98