Options:

Deepti Savio

Survival Kit for the RE Guy

Anecdotes from a Requirements Engineer in the Real World


In the context of that ubiquitous, all-situations-encompassing real world, the Requirements Engineer might move in and out of several concurrent projects, work across different domains, and deal with varying timelines simultaneously. The overload of the contextual switch between these projects is obviously anticipated and expected, but the experiences, know-how and key insights gained from doing RE for different types of projects might not be explicitly shared with other Requirements Engineers who may take over, mid project. Lessons encountered and learned might include dealing with various types of issues that arise from people-specific, project team-related, inter-departmental or organizational dynamics. Add to this melting pot the usual suspects of interplaying, nested levels of constraints that you need to work with, and it’s easy to throw your requirements specification templates up in despair, while trying to navigate through the situations at hand. This article discusses several conundrums that the Requirements Engineer may face during day-to-day project execution, and hints at one or more simple, easily implementable solutions or work-around techniques that might mitigate the undesirable effects of such situations.

So, here are some situations which many requirements engineers may be familiar with. I work in a research department, which has different groups working in specialized areas (both software- and hardware-related), performing proof of concept work and creating prototypes. In such an environment of relatively short-term projects, it is often the case that the requirements engineer (hereafter referred to as the ‘RE guy’) might have to work on several simultaneous projects, which may span different domains. This gives me a chance to encounter some interesting situations, such as working with different sets of customers and potential end users (at the same time), and interacting with shared project stakeholders, whose objectives and decision making capabilities vary across the projects they’re a part of, based on their respective roles, and so on.

In such a context, the RE guy needs to tactfully re-use and re-apply the insights he gains in one project across the other projects, as far as possible. So, even though this might sound mundane, I’m going to start off right here with lessons 1 & 2: L 1: Pay attention and L 2: Make the connects. I don’t only mean the obvious way of listening to what your stakeholders are telling you, but it’s very useful to listen out for what they’re refraining from telling you, and to what’s being said between the lines. A hesitation on the part of an architect to decide on a number for quantifying and documenting a non-functional requirement might be a constraint that could surface later on in the development phase, due to the fact that the reason for this missing number was not the architect, but a result of a procrastinated decision of another stakeholder higher up in the food chain, who didn’t want to commit to a hard performance value for his client. I know that this sounds like an additional chore on top of having to brace yourself and sometimes ask politically inappropriate questions to elicit information from the folks you work with, but the troubles and their respective work-around mitigation strategies described below are pretty straightforward, have helped me out fairly well (so far), and may, I hope, be of use to you, too.

L 3: (Why L 3? Refer to the second paragraph of the introduction. And please follow L 1). What to do when the RE guy isn’t aware of randomly disappearing project stakeholders.

This one’s one of my favourites. I once knew another RE guy (oh alright, fine, it was me), who used to attend weekly status update meetings where the key stakeholder responsible for a key module of the project would just be a different guy, every meeting. Why? There could be several reasons, the discussion of which is beyond the scope of this article. But my primary concern is that this occurrence, if not avoidable, needs to be shared with the entire project team, at periodic points in time, before parts of the team find out on their own. In this regard, it helps greatly if you maintain some sort of simple, visual stakeholder model in your requirements specification document itself or on a shared wiki. Alexander and Robertson’s Onion Model [1], Smith’s RACI Matrix, [2] and Ackermann and Eden's Stakeholder Interest vs. Influence Grid [3] are some good examples.

The second part of doing this is that you need to keep updating the information in these representations as and when these sort of changes occur. I stress “simple” so that everyone in the team doesn’t have to break their heads trying to figure out what they’re looking at, and can understand at a glance that, as of this point in time, this is the current scene with people in the project, their roles, and their levels of involvement (full, partial, expert consultant, etc.).

L 4: What to do when you’re not sure if a new requirement / a change to a requirement would be feasible within current constraints (and when you have to tell your stakeholders honestly right then and there).

So, everyone knows by now that requirements change. And everyone’s taken that for granted. I mean, yeah, I know I said that yesterday, but I want this today. In software-based systems, small changes may lead to significant amounts of system-wide impact on your existing architectural framework. Despite this fact being well-known, well documented and well argued ad nauseam, changes to requirements are still accepted by teams on behalf of their customer-facing stakeholder, who may not have carried out an impact analysis or some sort of what-if assessment to see how feasible they are within the given time, cost and resource constraints.

Speaking of these three constraints, as a starting point, one could try and use simple tools like the graphs shown in Fig. 1 below to weigh a change request from several perspectives - just to see if the team has reached consensus on which quadrant a new requirement or a proposed change would fall into, and whether or not a new requirement or a proposed requirement change is therefore doable or not. I stress current constraints here, because, like in most projects, constraints, like the resources (especially people), budgets and timelines, are likely to change. And another key point here is several perspectives – changes need to be evaluated from a technical as well as business standpoint, and not just by one guy who thinks the rest of the team ought to be able to swing it.

Explanation of Fig 1:

Figure 1: Placing requirements and requirement changes w.r.t effects on Time, Cost and Resource Utilization.

SP: Simple Projects: well known technology; existing similar systems, known customer / end-user base , well defined project scope and well understood, (relatively) stable requirements.
CP: Complex Projects: negation of (one or more of ) the factors listed above

L 5: What to do when you’re forced to accept infeasible changes to requirements.

Yes, you know as well as I do that despite the plethora of advice against doing so, this does happen. And when it does, you need to expand your resources line or your time line, or your cost line. Or preferably, two of these parameters. Or even better, all three, during those rare ocassions where you can wing it. The T-C-R triage is only the obvious primary set of constraints within which you have to build your requirements. There will be other secondary constraints (such as technical – dependencies on third party platforms, COTS modifications, legacy code that’s been ported, and so on, or business – we need to have this out in the market by the end of Q3 in 2015, to capture x% of the share, and so on), which are usually outside your control.

The consequences of trying to fit in requirement changes while not varying the restrictions on existing primary constraints can fall anywhere on a continuum ranging from mildly frustrating to disastrous, depending on both the type of change and its associated impact on the existing system plus project-specific constraints, plus the T-C-R numbers. If it’s a gotta-have change, well then, by all logical and rational reasoning, there has to be a negotiated gotta-wait-for-a-reasonable-extent gig to support it. Conversely, if time is critical, budget expansions for that new feature that your customer is willing to pay for, while agreeing to wait another three more months for onsite deployment, should also be doable. I know this is easier said than done, but if you can pictorially show them what’ll happen if you cram in more contents into the box that’s already full to bursting, hopefully they’ll get it.

L 6: What to do when you need to collaborate frequently with key stakeholders who are on the other side of the planet (or your building).

Nothing beats informal communication and unplanned, spontaneous random hallway / pantry chats in office. You glean a lot more real world project information and undocumented nuances of the actual status of the project from these sessions than you would after sitting with two cups of coffee through a two hour long meeting right after lunch with a presentation comprising 75 slides explained by a guy who’s probably as sleepy as you are. And in distributed projects, this part gets lost in translations across multiple time zones and between various cultures. So, set up a communication protocol. Before you get into sprint 1, or sign off on that milestone. There’s (often) no point trying to figure out a pattern of communication as and when you go through the project and seeing what works and then whine about how you mailed the guy last week and sent him a reminder three days ago, and he still hasn’t gotten back to you (note to self). Get to know your stakeholders if you can. Find out where they’re from, and what projects they’re doing, and if they love Pixar movies and Alternative Rock or hate Man U and spicy food. Connecting with your stakeholders and taking pains to see that they’re comfortable around you is the first step in gaining their trust, and the ramifications of doing this usually go far beyond your current project. If it’s a stakeholder you don’t know, then you can’t really fathom when he’ll respond to email, how urgent he thinks what you’ve asked him is, or how often he would like you to update him on what’s going on. And you can’t make these assumptions for him based on what you think.

Changes in communication protocols are one of the key problem areas in projects. This is especially true for teams transitioning from traditional waterfall-ish methods to something like agile [4]. It’s simply because people don’t really know whom they should talk to or go to, and when they should do this, and how often. In this regard too, along with establishing some form of communication pattern that needs to be adhered to throughout the project by all participating stakeholders, the suggestions for dealing with the conundrum stated in L3 may come in handy. Additionally, Livemeeting [5] and WebEx [6] are some great video conferencing collaboration tools that can be made use of while having meetings with folks in multiple places. The body language and expressions of the other guy, even if he’s behind a screen, might tell you a lot more than phone conversations and emails would.

L 7: What to do when you don’t really know the domain.

One of the first projects I ever worked on as a newbie straight out of college was helping a team refine and detail out low level user stories and acceptance criteria for a medical application that they were developing for a healthcare system. And boy, did I feel quite daft in that first meeting, not knowing that a vascular surgeon is different from a cardiac surgeon, and that both of these aren’t the same as an interventional cardiologist. So as an RE guy, you need to be painfully aware that it might not always be possible for you to zero in on one domain, and eventually get to be a subject matter expert there, especially if you work on multiple projects at the same time, that may be in different domains.

The first thing you need to do in this scenario is skip disbelief, anger, frustration and denial completely, and go straight to acceptance. Accept that people will go ‘hmph’ when you ask a domain-related question that everyone else in the room already knows, accept that you can’t become a domain expert in two days or two months, and accept that you can’t read the entire internet overnight, even though others may expect you to. When you do land up here, I’d recommend (apart from a Basics for Dummies, and a terminology-specific dictionary) sitting in for some of these technical discussions and trying to catch a few key terms and phrases. You’d be surprised at how much you’ve been able to pick up after a few such meetings.

Another thing to do is to explicitly schedule a fair amount of time as part of your required competence ramp up to do a good job in delivering a quality requirements specification. From what I’ve seen, if you explain why you think you’d take a week longer that envisioned to send out that first cut draft of requirements, most folks in the project would willingly agree to give you that extra time. Or at least half of it. And when you do write up that SRS, put forth your fabulous and newly acquired know-how into a glossary section with all these terms explained, with links for further information, so that the next clueless RE dude who may just find and read the SRS you wrote long after your time will be able to understand it a little better. Glossaries and context specific definitions of terms are always useful, not only for the current project, but even for archival reading and similar projects.

L 8: What to do when you and your stakeholder hit it off so well, you forget to discuss requirements.

So, after a few rounds of conversation, it’s clear that you don’t get along with the other guy. Or, maybe you just don’t like him, and he doesn’t like you. But you need to get requests, requirements and information from him, anyway. This can also happen in a discussion with several stakeholders who might not be the best of pals – which is where your facilitation, moderation and diplomacy skills as an RE guy – coupled with a neutrally polite and objective outlook – are highly recommended.

When you find yourself talking about everything else but your project, or if you see that you’re going off key and off tangent to diffuse a sticky conflict you can sense in the offing, bring your conversation back on track (and that awkward meeting to an end) by reiterating the points you’ve agreed to agree on, and revisiting those areas where you’re yet to reach a consensus. And oh, document the reasons for which agreement hasn’t been reached, as of that point in time. And send it across on that day in a follow up email. Or better yet, highlight these points and put them up on the shared repository.

Decision points, uncertainties, incomplete information and un-analyzed dependencies, which may become blocking issues in the future, are an important input to justify why the current set of requirements or the present sprint backlog looks like it does. These points of rationale are usually not explicitly captured and stated along with requirements, and might get lost in tangled email chains, proving rather difficult to fish out a year (or three) later. As an RE Guy, you know that decisions and rationales have to be captured, just like requirements need to be recorded along with their source or point of origin, for what I like to call ‘sensible’ traceability. Just make sure that your stakeholders see the value in doing this, too.

L 9: * Shared *

The term ‘shared’ brings its own set of complex implications for the RE dude. Shared… what? Resources, who are working on multiple projects? Codebases? Know-how? Labs and floating software licenses? Work products? Whatever sharing you may be doing in your team, it’s important to know who it’s being shared among, and how much each party gets / does / and to what extent, and with what frequency the sharing is to be done, and then seeing if it’s actually happening with that frequency. Most important of all, the shared stuff needs to be accessible immediately to everyone who needs to access it. This can be mighty difficult when you have teams who just don’t know each other, or teams who aren’t that comfortable with each other, and may get into a cold war mode while doing shared work for a project.

So, what happens with distributed teams where it’s difficult to access these shared resources? If you don’t get access to a piece of information that will play a critical part in shaping your requirement, or a presentation with the wireframes that you really need, document it. When I say document, I don’t mean put it into the Requirements Spec doc saying that “MRS 1.1.2_UID Req 24(a) isn’t updated because Hector never sent across that file he told me he would like, a month ago”. No, it’s important for RE guys to maintain a personal document – a sort of project-specific journal (and heck no, no one else should get a peek into it)! This record is your key source for implementing Lesson L2 – the insights from this could form the missing link between two apparently unrelated requirements, and serve as points of rationale later on when you’re writing requirements. And remember, this record is exclusively for you. Which brings us to our last lesson for today.

L 10: Information invisibility… for reasons reserved.

Different people in the project have different levels of access to project, project-ish and non-project related information. And they may or may not choose to divulge that to other folks in the project, as mentioned previously.

When you go in for a brainstorming session, or an informal chat with a stakeholder, you need to maintain notes of what you’ve learnt. Confidentially, just for yourself. They’re a critical source of information about requirements, deadlines, dates, people, their opinions, their roles and availability, and most important of all - technical, managerial and organizational decisions made at a specific point in time. They’ll also contain your ideas on how to link lines, meeting statements, quotes, constraints, diagrams, disagreements, arrows, smiley faces, footnotes and scribbles and create a requirement from it all. And, to no one’s surprise, we know that one of the most important deciding factors for what becomes a requirement are the decisions themselves. You can’t even begin to fathom some of the reasons that may be behind the decisions that you see being made – but nevertheless, decisions, like requirements, constraints, tax benefits and new year resolutions, are valid only for a particular period of time. And hence need to be captured, lest you forget. If you pull up a previously baselined SRS and can’t figure out why SRS-es 10 – 16 were deleted, well, that isn’t an ideal situation to be in. Link requirements with the decisions that were made for why they are or aren’t in the specs. Just like you’d ideally want to link a high level requirement to its original request and the stakeholder(s) who supplied that request.

Conclusion:

There are a lot more situations that an RE guy can encounter. And I don’t want to write them all down and turn this into a book, because I know we never have as much time as we’d like to do a clean job of eliciting, analyzing, validating, specifying and managing requirements already, usually for n>3 projects that are running simultaneously, with clashing deliverables and deadlines. It’s important to remember that the magnitude and impact of the situations described above may be different at different points in the timeline for the same project, and that you usually need a combination of ready-to-be-used, easy-to-follow techniques and people skills to handle these conundrums as and when they arise. I know that most of the stuff I’ve written is common sense, but it’s pointless having tacit common sense and not exhibiting it at the optimal time, especially as an RE guy. The timing is very important. With any luck, little pieces of know-how-and-when such as L 1 - L 10 may help us get to our objective a little faster, and with a little less gray hair. And the non-RE folks reading this should have hopefully acquired at least a marginal increase in their empathy levels for us and try and help us out in our usually optimistic, sometimes hopeless, yet ever determined quest to keep the customers and the end-users and the project team and all their managers just a little more satisfied.

References and Literature



Deepti Savio

Deepti works at the RnD Department of Siemens Corporate Technology, Bangalore. Her responsibilities include RE consulting, applied RE research, and delivering in-house RE and Scrum Trainings. Her research interests include handling requirements in agile development, and requirements visualization. Deepti has a Masters in Software Engineering from the University of Melbourne, and is an IREB-CPRE. She still enjoys writing neat, unambiguous requirements specifications in structured templates and striving to get stakeholders to read them.