please recommend some good books for software engineering

Posted on 2006-06-18
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
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 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 )

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 25 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
Announcing the Most Valuable Experts of 2016

MVEs are more concerned with the satisfaction of those they help than with the considerable points they can earn. They are the types of people you feel privileged to call colleagues. Join us in honoring this amazing group of Experts.


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 25 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

Enroll in June's Course of the Month

June's Course of the Month is now available! Every 10 seconds, a consumer gets hit with ransomware. Refresh your knowledge of ransomware best practices by enrolling in this month's complimentary course for Premium Members, Team Accounts, and Qualified Experts.

Question has a verified solution.

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

Dependencies in Software Design In software development, the idea of dependencies ( is an issue of some importance. This article seeks to explain what dependencies are and where they …
Introduction This question got me thinking... ( Why shouldn't we use Globals? This is a simple question without a simple answer.  How do you explain these concepts to a programmer w…
If you're a developer or IT admin, you’re probably tasked with managing multiple websites, servers, applications, and levels of security on a daily basis. While this can be extremely time consuming, it can also be frustrating when systems aren't wor…
In this brief tutorial Pawel from AdRem Software explains how you can quickly find out which services are running on your network, or what are the IP addresses of servers responsible for each service. Software used is freeware NetCrunch Tools (https…

707 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