This is the first in a series of my answers to Jurgen Appelo's list of 100 Interview Questions for Software Developers. Jurgen is a software development manager and CIO at ISM eCompany, according to his About page.

The list is not intended to be a "one-size-fits-all, every developer must know the correct answer to all questions" list. Instead, Jurgen notes:

The key is to ask challenging questions that enable you to distinguish the smart software developers from the moronic mandrills.
...
This list covers most of the knowledge areas as defined by the Software Engineering Body of Knowledge. Of course, if you're just looking for brilliant programmers, you may want to limit the topics to [the] Construction, Algorithms, Data Structures and Testing [sections of the list]. And if you're looking for architects, you can just consider the questions under the headings Requirements, Functional Design and Technical Design.

But whatever you do, keep this in mind:
For most of the questions in this list there are no right and wrong answers!

Keeping that in mind, I thought it would be fun for me to provide my off-the-top-of-my-head answers, as if I had not prepared for the interview at all. The format will first list the question, my initial response (to start the discussion), followed by a place I might have looked for further information had I seen the questions and prepared before answering them.

Though I hope otherwise, I may fall flat on my face. Be nice, and enjoy.

Requirements

1. Can you name a number of non-functional (or quality) requirements?
   I'd first mention performance and security, from the user's perspective. I'd then mention meeting minimum requirements for metrics like code coverage in testing and dependencies in our design. I don't consider code quality out-of-order when it comes to requirements.
   
   The non-functional requirements page at Wikipedia lists several examples. Notable exceptions from my quickie-response: accessibility, documentation, portability. There are several that are listed that I consider covered by what I've listed, but I missed some that caused me to say
   
   
   
   
2. What is your advice when a customer wants high performance, high usability and high security?
   My "advice" starts with the questions: "What do you consider X to be?" where X belongs to the set {"high performance", "high usability", "high security"}. I might offer that I consider "high performance" to be a misnomer, as it's either acceptable or not, and that unless the customer defines it, I don't know how we'd even attempt to measure something as vague as "usability."
   
   I'm not sure where I'd prepare for this question. Any suggestions are appreciated.
   
   
3. Can you name a number of different techniques for specifying requirements? What works best in which case?
   I can name several: tell me in person, tell me over email, tell me over IM or over the phone. I know that's not what you're looking for. You're looking for answers like "use cases." It all boils down to the same. I might even mention "unit tests" here. That's part of the spec, as far as I'm concerned, and for almost any software I write for myself, it's the only way I specify requirements (except for maybe a very informal to-do list).
   
   Face-to-face works best in most cases, I'd gather.
   
   The answer after doing some research: ¡Ay, ay, ay, no me gusta! I didn't see this coming. There are a number of things that could qualify as answers (Prototyping, Storyboards, Modeling, ..., State transitions) that I knew about beforehand. I thought to include none of them.
   
   
   
   
4. What is requirements tracing? What is backward tracing vs. forward tracing?
   My response? "I don't know anything about requirements tracing. I'm willing to learn."
   
   Once again, Wikipedia tells us about requirements traceability, illuminating the issue for us.
   
   
5. Which tools do you like to use for keeping track of requirements?
   I generally use a combination of a text file and emails, as far as the client is concerned. If it's a larger system, I'll use something like Sharepoint, Basecamp, or another system that performs a similar function. I have no preferences, because nothing I've ever used compares to a simple list. If it does, it's equally useful.
   
   I don't know that I'd say I like any of them. In reality I prefer a simple to-do list that I encode in tests (insofar as I'm capable of writing the tests) and knock them out one-by-one.
   
   
6. How do you treat changing requirements? Are they good or bad? Why?
   I don't give a value judgement on changing requirements: they are inevitable. They can be good or bad depending on how the client handles them.
   
   I always try to let the client know: I can do X amount in Y timeframe. You asked for Z total. Here's an estimate for each item in Z, pick X from it for our current Y timeframe. I'll get back to you every Y timeframe to show a demo, and you can choose X from the remaining Z again (with changes based on circumstances if required). Feel free to fire me when you have enough out of Z that's functional. (Ok, I probably wouldn't say the last sentence in those terms, but I'd find a way to say it, if for no other reason than to sell them the rest of the process.)
   
   As far as looking it up before the interview: I've review Agile literature. Searching any of the agile yahoo groups for the question at hand ought to be good enough.
   
   
7. How do you search and find requirements? What are possible sources?
   "What do you mean?" would be my response. I really don't know. What does searching and finding requirements mean? Does it mean figuring out how to do requirements that I don't know how to accomplish?
   
   If so, the first step is Google. In the rare event no one that I can find has had my problem, I'll go traipsing through the source code if it's available.
   
   Clearly, I don't know where to start here.
   
   
8. How do you prioritize requirements? Do you know different techniques?
   I rarely prioritize requirements. I let the customer decide. I give them a relative cost of implementing X requirement vs. implementing Y requirement, and let them decide. If Y requires X, then I tell them so.
   
   I know of different techniques - take "random" for example. I don't know what they might be called. But I cannot think of anything better, even if it were decreed as a Top 10 Commandment for Prioritizing Requirements.
   
   No web search for this comes to mind. I'd review a couple of process management books if I had no clue. This seems to be a decent discussion, if you must have one from me from a cursory browse.
   
   
9. Can you name the responsibilities of the user, the customer and the developer in the requirements process?
   The user will be the person using the software, versus the customer being the one who pays for its development. I hate that distinction. The developer programs it. Responsibilities? In my ideal organization, I'd have:
   • Developers working with the Customer to manage requirements.
   • Developers working with the User to make the application work for them regardless of the Customer (I've seen too many projects where the User had to use whatever the Customer purchased, even if the purchase was ... little yellow bus-ish.)
   • Customer/User having daily meetings with the developer
   • Developer making the best software he/she can given the constraints.
   Again, I don't know where I'd look this up before being asked. Suggestions (again, as always) are most welcome.
   
   
10. What do you do with requirements that are incomplete or incomprehensible?
    I send an email saying "I don't understand what you mean. Please read the very small attached book and get back to me."
    
    
    
    Just kidding, of course (at least in most cases. I've been recently tempted to send that exact email, as it happens.)
    
    I just ask them to clarify. If I don't have contact with the customer, I ask the intermediary to clarify or get clarification.
    
    Outside reading: Agile, and hopefully other processes for some compare and contrast.
    
    

I think these are decent answers to start a discussion with. If you're a hiring manager, what do you say? Would you show me the door, or keep me around for a while longer?

It's not quite as hard as Steve Yegge's list of things to know (I'll get to that eventually), but it's a good (and more well-rounded!) list nevertheless.

How would you answer the Requirements questions?

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

Leave a comment

















Leave a comment

Leave this field empty

	Your Name
	Email (not displayed, more info?) Privacy Information x Your email address is not displayed. It is used only to respond to you if needed, and send comments if you subscribe to this comment thread. It is stored in a cookie if you choose to "Remember my details".
	Website

Comment:

Subcribe to this comment thread
Remember my details