SEARCH
0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Prev | Current Page 77 | Next

Margaret K. Kulpa, Kent A. Johnson

"Interpreting the CMMI: A Process Improvement Approach, Second Edition"


Writing standards for what a Requirements Specification should look like is
a product focus. You are focusing on the template itself. For example, you might
want your Requirements Spec to list all of the requirements for the system, categorize
them as to whether they are system-level requirements, software requirements,
hardware requirements, safety requirements, performance requirements,
and so forth. Great, this is a good thing to do. But, how does anyone know which
n n n n
Beginning the Journey n 21
categories they fit in? This is where a requirements process comes in. It would tell
you not only what the spec should look like, but how to write it??”how to fill in
the blanks for each paragraph in the spec. A requirements process would also tell
you how to elicit requirements from your stakeholders (e.g., customers, end users,
requirements analysts) and how to manage the changes to the requirements. The
product focus would then continue on to what a Design Spec should look like, what
coding standards should be followed, what test cases should consist of, and so forth.


Pages:
65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89