I have seen and read quite a few books about software design (using UML, etc.), and others about user experience, GUIs, etc. but I'm looking for books that describe the process that happens before all of that.

I'm looking for the pre-development stuff. How to develop a cohesive and comprehensive plan for what the application is functionally supposed to do, leading to flow-charts and a functional specification, etc. So I guess my question is in two parts:

Is there a book out there that's the de-facto standard for describing best practices, design methodologies, and other helpful information about functional requirements analysis? What about that book makes it special?

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

closed as off-topic by gnat, user40980, Dan Pichelman, Kilian Foth, Bart van Ingen Schenau Nov 14 '14 at 13:03

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – gnat, Community, Dan Pichelman, Kilian Foth, Bart van Ingen Schenau
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    Hi tjb1982, open-ended book recommendation questions don't work well here, as they tend to be a list of people's favorite book with no explanation about why the books are any use. I've revised your question to better fit with what types of book questions we do allow here. For more information, check out Are book recommendations on-topic?. – user8 Oct 21 '11 at 20:38
  • That really gets to the heart of what I was trying to ask anyway. Thank you. – user25791 Oct 21 '11 at 20:49

When it comes to requirements specifications, my go-to books are Karl Wieger's Software Requirements and More About Software Requirements. Together, these books discuss the majority of the topics needed for requirements engineering, from defining stakeholders and requirements to establishing a vision and scope to capturing and prioritizing requirements.

Software Requirements tends to focus more on specifications and requirements engineering techniques. More About Software Requirements discusses other methods of capturing requirements, such as use cases and determining the detail needed in the documents that are used to capture requirements.


Functional design is I reckon a bit of an older term used during the times (D)SDM was popular. I reckon nowadays it's called Analysis or gathering requirements.

I've been introduced to the subject of requirements analysis through a book written by Ian Sommerville called "Software engineering" That helped me put processes involved in creating software in perspective. The book explains what needs to be acomplished, why and how it can be done.

Ian Sommerville also has written a book on the specific subject of requirements analysis. http://www.amazon.com/Requirements-Engineering-Good-Practice-Guide/dp/0471974447/ref=sr_1_5?s=books&ie=UTF8&qid=1319274316&sr=1-5

  • 1
    "Go look somewhere else" is not an answer. Check out the post notice. – Matthew Read Oct 22 '11 at 4:28

The best books I have found regarding the things a programmer should do before coding are:

  • Frederick P. Brooks, The Design of Design: Essays from a Computer Scientist Paperback. Brooks is also the author of the outstanding Mythical-Man Month book (also recommended, however the scope of this one is more on the project management side of software). In The Design of Deign, Brooks talks about the problem and design exploration process.
  • Michael Jackson, Software Requirements and Specifications: A Lexicon of Practice. This is a syllabus on very different concepts that appear during the design and requirements phases. The books is organized as a dictionary which is unusual. I have learned something from each entry.
  • L. Lamport, Specifying Systems. This is the more mathematically oriented, and therefore, hard. This book is specifically targeted to writing formal specification using TLA+ formalism. From this book I learned how difficult and nevertheless beautiful is the specification of concurrent systems. Notice that there are other formalisms and tools, however this book is really a gem.