please recommend some good books for software engineering

Posted on 2006-06-18
Medium Priority
Last Modified: 2013-11-12
I need to write a software document which includes requirement spec, functional spec and design/technical spec.  My knowledge is still about 10 years ago and I forget most how to write a organised software spec.  For now, it seems that requirement and functional spec are mixed up together.  Before data flow diagram was included in the functional spec. But it seems that now the diagram is not so popular.

Therefore, I want to update myself to see any good software enginnering books are recommended?  It is better to have guidelines or examples, which topics or information/diagram should be included and which should not be included  in each of the  3 specs, e.g. the interaction diagram is included in functional or design spec, etc.?

Question by:Torus
  • 4
  • 2
  • 2
  • +1

Expert Comment

ID: 16932487
UML is just about the standard for writing technical / design and functional specifications.  Although UML distilled is a small book (less than 200 pages) it's very readable and explains just about everything to do with UML.

UML Distilled - A Brief Guide to the Standard Object Modeling Language ( Martin Fowler )
See http://www.amazon.com/exec/obidos/tg/detail/-/0321193687?v=glance

I was going to recommend more books, but to be quite honest if you have a background in doing things before, then this ought to be all you need :)


Author Comment

ID: 16934511
When I learnt software engineering 10 years before, there was no UML. However, UML is only technical format or diagram in the document.  What I need is the documentation format, i.e what content should be included in requirement spec, functional and tehnical spec, not just how to draw a technical diagram, UML, etc. instead I want to know what diagrams should included in which specs.

I think maybe software engineering books talking about how to write a spec is more appropariate to me.
Actaully, I really forget most of the format and some new presentation formats are likely added within these 10 years.

LVL 15

Accepted Solution

lakshman_ce earned 100 total points
ID: 16946397
Please refer to this link

Also I would suggest the following books
Software Requirements: Styles and Techniques by Soren Lauesen
Mastering the Requirements Process by Suzanne Robertson, James Robertson
Vote for the Most Valuable Expert

It’s time to recognize experts that go above and beyond with helpful solutions and engagement on site. Choose from the top experts in the Hall of Fame or on the right rail of your favorite topic page. Look for the blue “Nominate” button on their profile to vote.


Author Comment

ID: 16960833
BTW, then what is the different between requirement spec and functional spec? They are quite similar rite now
LVL 15

Expert Comment

ID: 16962095
Requirements Specification is a formal statement of what the product planners informed by their knowledge of the marketplace and specific input from existing or potential customers believe is needed for a new product or a new version of an existing product. Requirements are usually expressed in terms of narrative statements and in a relatively general way.

Objectives for the software product are written by product designers in response to the Requirements. They describe in a more specific way what the product will look like. Objectives may describe architectures, protocols, and standards to which the product will conform.

Functional specification is the formal response to the objectives. It is used to describe in detail for software developers a product's intended capabilities, appearance, and interactions with users. The functional specification is a kind of guideline and continuing reference point as the developers write the programming code.Typically, the functional specification for an application program with a series of interactive windows and dialogs with a user would show the visual appearance of the user interface and describe each of the possible user input actions and the program response actions. A functional specification may also contain formal descriptions of user tasks, dependencies on other products, and usability criteria.

Requirements specification document is the output of the Requirements Gathering phase
Functional Specification document is the output of the Requirements Analysis phase.
These phases are followed by design, coding, testing , release etc if required.

Hope you are clear now.


Author Comment

ID: 16969426
Thanks lakshman ce.   Why I asked this because I am quite confusing about these 2 specs recently. Before I wrote these specs( about 7-8 years ago) which  boundaries are specified quite clearly. However, when I see some specs recently, it seems that some will mix up 2 specs together(or informal?), e.g  performance, software and hardware requirement are specified either  requirement or functional. Even some user requirement will sepcify in the functional spec and some functions will specify in requirement.  I think now some topics can be  specified either in the 2 specs.


Assisted Solution

blueforce earned 100 total points
ID: 17105305
I think a good place to start if you're looking for contents and layout are the IEEE std. 830-1998 and IEEE std. 1016-1998 documents.

IEEE std. 830-1998 is the "Recommended Practice for Software Requirements Specifications" and 1016-1998 is the "Recommended Practice for Software Design Descriptions".  Both are widely used, as are most of the IEEE std. documents including 1074 and 1058 which are the "Standard for Developing Lifecycle Processes" and "Standard for Project Management Plans respectively".  What you'll find is that the IEEE documents "flow" in an almost linear fashion.  They're designed more or less to follow a software engineering process which begins with concept exploration through the SDLC development and retirement.  Which is to say that some sections and wording used in the first document are repeated in successive design documents.  That isn't to say that a requirements spec couldn't be used as a stand-alone document either.  You'll find that there are many formats available for creating requirements specs and many times they're just derivatives of the IEEE docs.  Dr. Roger Pressman has a proprietary "Adaptable Process Model" which is a hybrid of his own approach and the IEEE standards.

The most important thing about requirements is that they should be:

* correct - every requirement meets a user need.
* unambiguous - no interpretation variations in the spec
* complete - everything the software is suppose to do is included.
* verifiable - must be a method to verify every requirement. This can be a function of how the requirement is writtten. Don't use "usually", "often", "user friendly".
* consistent - no confilicts should exist.
* modifiable - should have an index, table of contents for easy referencing.
* traced- the origin of each of its requirements is clear.
* traceable - each requirement should be identifiable. Each * requirement should be have a unique number.
* design independent - no design constraints should be mentioned, it does not imply a specific software architecture or algorithm.
* annotated - can catgorize requirements.
* concise - keep it short and simple.
* organized - must be organized and each requirement should be easily locatable.
* understandable by the customer - keep the language simple, don't use "computer science" type notation

The reasoning behind the uniqueness and numbering is for testing and traceability later on.  A white box tester with no knowledge of your application should be able to test every requirement for a specific result.

UML is simply a modeling language, which is good for representing use cases, but is not a requirements spec in and of itself.  You will find UML use-case diagrams within a requirements spec.  You may also find data flow, E-R diagrams, and state charts too.  The diagrams aren't necessarily required nor are they explicitly indicated.  The problem you are solving and the situation you are presenting will dictate which type and how many diagrams you need.

Regarding books, there are a number of good books available on a variety of topics.  One of my favorite books on software engineering is actually one of my textbooks from grad school called "Software Engineering", ISBN 0-8186-7609-4.  It is not a texbook in the traditional sense, it is a collection of some of the best peer-reviewed papers in the field and book excerpts on software engineering such as "The Mythical Man Month".

Author Comment

ID: 17159136
who's the author of that book? difficult to search the book if just have ISBN.


Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Ever wonder how to "do" object oriented programming (OOP)?
Introduction This article explores the design of a cache system that can improve the performance of a web site or web application.  The assumption is that the web site has many more “read” operations than “write” operations (this is commonly the ca…
Is your OST file inaccessible, Need to transfer OST file from one computer to another? Want to convert OST file to PST? If the answer to any of the above question is yes, then look no further. With the help of Stellar OST to PST Converter, you can e…
As many of you are aware about Scanpst.exe utility which is owned by Microsoft itself to repair inaccessible or damaged PST files, but the question is do you really think Scanpst.exe is capable to repair all sorts of PST related corruption issues?
Suggested Courses
Course of the Month13 days, 10 hours left to enroll

749 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question