• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 265
  • Last Modified:

please recommend some good books for software engineering

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.?

  • 4
  • 2
  • 2
  • +1
2 Solutions
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 :)

TorusAuthor Commented:
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.

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
Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

TorusAuthor Commented:
BTW, then what is the different between requirement spec and functional spec? They are quite similar rite now
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.

TorusAuthor Commented:
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.

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".
TorusAuthor Commented:
who's the author of that book? difficult to search the book if just have ISBN.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

  • 4
  • 2
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now