2D1363, Mjukvarukonstruktion, 8 poäng

Aktuell kursomgång: period 2-4 06/07

Kursledare: Rand Waltzman
Datorpostadress(er): rand@nada.kth.se

 

Homework 7B:  Due 5/2/2007

See Homework page for general information. 

Requirements Document Evaluation

 

Your assignment is to evaluate and score the Requirements Document produced by an anonymous team of your classmates.  Your group leader will be receiving the document by e-mail.  If you have not received this document by 1800, Monday, January 28 please let me know immediately.  This is a group effort.  One anonymous evaluation has been sent to each group and each group will turn in one evaluation.

 

For each of the items below, you must give a score up to the maximum points shown next to each item together with a written justification.  Total possible points are 100.  Each justification must contain at least one example from the document that illustrates your point.  A quote without comment is not acceptable as a justification.  What is required is a quote plus your comment.  For example, “the document said ‘X’ which I find to be ambiguous because it can be interpreted as meaning either ‘Y’ or ‘Z’.”  If it is a diagram that you are commenting on, you only need to refer to the diagram and describe what you think is right or wrong with it.  In items that are phrased like “Does the Preface do ‘X’?” you are not only being asked whether the Preface does ‘X’ at all, but how well it does it, etc.  Of course, if ‘X’ is not being done at all, then the item gets 0 points.  If it is being done in a completely unacceptable way, it also gets 0 points.

 

Your evaluation must have the following format:

  1. Cover page with your Group Number and a list of all group members.
  2. For each item on the checklist:
    1. First line is a number and the checklist item description as copied out of this document.
    2. Next line is your score.
    3. Following lines are your justification.

 

If your evaluation does not follow this format exactly, I will bounce it back to you and will be penalized.  The work will be counted as late with the usual penalty points until I receive a satisfactory version.  This is to be turned in as a PDF file.  The e-mail header must be of the form:  2D1363 RDE Group ‘X’.

 

Here is a suggestion about how to do this with your group.  First, each member should read through the evaluation checklist below so s/he knows what to look for in the RD you have received.  Then, with that in mind, each member reads through the RD making careful notes.  Assign one member of your group to take the checklist items and put them into an editable document.  Finally, get together as a group, go through the items in the list one by one by discussing them based on notes each member of the group has taken while reading the document, decide how to answer each item and fill in the item on the fly.  By the end of the meeting, the evaluation is ready to submit!  I think you will find this method very practical and effective.  On the other, you are, of course, free to do this any way you like.

 

Evaluation Checklist Items:

 

  1. (5) Does the Preface describe the document’s expected readership?
  2. Does the Introduction:
    1. (5) Explain the need for the system.
    2. (5) Present an overview of the system’s functionality and how it will work.
  3. (5) Does the Glossary define all technical terms used in the document without making any undue assumptions about the level of expertise or understanding of the reader?
  4. Does the User Requirements section describe or specify:
    1. (5) The services provided for the user, i.e., the functional requirements.
    2. (2)The non-functional requirements.
    3. (6) Behavioral descriptions using use cases.
  5. Does the System Architecture section:
    1. (5) Present a high level overview of the anticipated system architecture.
    2. (3) Show the distribution of functions across system modules.
  6. Does the System Requirements Specification section:
    1. (5) Describe the functional and non-functional requirements in more detail than the User Requirements Definition section.
    2. (5) Specify behavioral descriptions with use cases.
    3. (5) Show the trace back to the user requirements from each of the system requirements.
  7. (5) Do the appendices provide detailed and specific information which is related to the application which is being developed such as:
    1. Hardware descriptions.
    2. Minimal and optimal configurations for the system.
    3. Data base descriptions.
    4. Logical organization of the data
    5. Relationships between the data
  8. (3) Does the document provide an index (or indices)?
  9. (3) Is the language clear and easy to understand?  Is it concise and doesn’t hide the main points behind a wall of words?
  10. (3) Are all statements unambiguous or is there any room for interpretation?
  11. (3) Is the specification written from the perspective of the reader (as opposed to the writer)?
  12. (3) Is the information organized to make it comprehensible to a newcomer (rather than convenient for the author)?
  13. (3) Is the specification complete?  Or does it leave a lot of unanswered questions?  (References to other documents are OK as long as the reference is precise and will allow the reader to easily locate the document and the referenced information within the document.)
  14. (3) Are all statements consistent?
  15. (3) Are the requirements being detailed in a consistent manner? 
  16. (3) Are the requirements testable? 
  17. (3) Is the document written using a structure that allows modifications?
  18. (3) Are all inputs to each function sufficient to perform the required function?
  19. (3) Are undesired events/inputs considered and their required responses specified?
  20. (3) Have the preconditions and post-conditions, and exceptions been defined for all system operations?

 

^Upp till Nadas kurser.

Sidansvarig: <rand@nada.kth.se>
Tekniskt stöd: <webmaster@nada.kth.se>