So, What is Requirements Work?

Interesting article from the Spring Issue of IEEE Software entitled, “So, What is Requirements Work?”.  The author, an obvious expert in the field, goes on to conclude that Requirements Work is basically helping people help themselves.  I like this definition.  As a Requirements Analyst, you cannot know every single domain you will be parachuted into as your career progresses.  No one can be an expert in Medicine, Law, Accounting, Botany, etc.  Instead, “smart” Requirements Analysts depend on the domain experts that already exist to guide them to the problems that need to be solved.  Then, they are able to get out of domain experts/stakeholders the specifications of those problems.  Finally, the requirements analyst can specify those requirements in formats that are decipherable by multiple stakeholders (developers, customers, etc.).

I’m not sure I agree that Requirements Work involves coming up with solutions though.  It seems to violate some central core of Requirements that were taught to me, “Concentrate on the problem, not the solution.”  But, I’ll admit as a former software developer, I can’t help to think of solutions when I hear problems.  I have to be judicious, though, about when I bring them up.

Check the article out yourself when you get the chance!


About Leonard Woody
Software Engineer

8 Responses to So, What is Requirements Work?

  1. Martin L. Shoemaker says:

    At the end of one week of requirements gathering, the clients asked me, “How did you know so much about our work?” I answered: “I didn’t. I still don’t. You did. I just know how to show you what you said.”

  2. Nice! Thanks for the comment! 🙂

  3. myvoltandleaf says:

    Most analysts are unclear what it means to be one in 2013. More so in this environment than ever, where IT is moving towards hybrid resources versus silo’d ones (the trend to nearshoring or back to onshore development) with analysts and developers being more well-rounded technologists rather than specialists, it’s critical for analysts to know how to get at business problems, and then have the know-how to derive appropriate solutions for them AND have enough technical expertise to verify and challenge conceptual and technical designs proposed by architects and programmers. I mentor this wherever I go: the analyst is THE most critical project role. But the days of the “requirements” analyst are nearly over. As we enter a time in history where it’s almost mandatory to be bilingual in some programming language, the role of the analyst, while still ambiguous, is evolving again. An analyst that can define a biz problem, address it through an effective conceptual design that is made efficient through an appopriate technical design, rare, is the future, and is worth their weight in MIS gold.

    • You raise good points. I think good analysts are worth their weight in gold and it involves very different skills from programming. Having observed untrained programmers trying to be analysts, it can be very frustrating to users who “just want a working system”. I think the pendulum will swing back again away from generalists after our industry sees some of the disasters that can result from bad requirements.

      • myvoltandleaf says:

        Hi Leonard! We agree. However I think that, as with other industries and jobs, as technology knowledge becomes more and more a prerequisite, there’s going to be a contraction of employees and a consolidation of roles. To me, skills isn’t the challenge (those can be taught, and acquired). The bigger question to me is personal archetype. In other words, the innate qualities of an individual that makes them an outstanding developer are not the same traits that make another a stellar BA. Same with project managers. In hiring, I’m moving towards less low cost offshore development and more towards investing the time into generalists and technologists that can play those dual roles. Right now, they’re hard to find because it’s not the way we’re educating folks. But there are quality gains as well as budget gains in having a smaller team that is maybe higher paid but plays a different role effectively depending on the sdlc phase. What are your thoughts?

      • I like it and is basically the model proposed by Scrum (which you probably know 🙂 ), a “cross-functional team”. But you also rightly point out that these people are very hard to find and demand quite a premium salary-wise. Bravo to you for understanding this. Many managers I come across as a consultant do not unfortunately. It’s something Steve McConnell has been preaching for a very long time on his “10x Productivity” articles.

        Managers look at software engineers as factory workers and hence can’t believe one software engineer could be worth double much less 10 times more than another. The other thing that hinders this is the lack of professional accreditation software engineering has. It’s very hard to determine in a one hour interview if the interviewee is one of these special people. Doctors and lawyers are much better at this, but of course they’ve been doing it longer too 🙂

      • myvoltandleaf says:

        I hadn’t read McConnell, but I will now 🙂 a pleasure chatting and reading your blog 🙂

      • Martin L. Shoemaker says:

        Let me add a vote for McConnell, pretty much every book he has written. Start with “Professional Software Development”, then “Software Estimation”.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: