13.07.2015 Views

Part 4 - Iowa Medicaid Enterprise

Part 4 - Iowa Medicaid Enterprise

Part 4 - Iowa Medicaid Enterprise

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

RFP MED-12-001 | Technical Proposal<strong>Iowa</strong> <strong>Medicaid</strong> <strong>Enterprise</strong> System Service Procurement | MMIS and Core MMIS OperationsAttribute Definition CommentsVerifiableModifiableTraceableFeasible(Achievable)Understandable• Individual requirement: A requirement is verifiable if, and only if, there existssome finite cost-effective process with which a person or machine can checkthat the software product meets the requirement.• Each requirement is stated in concrete terms and measurable quantities. Aprocess should exist to validate that the product (when developed) will satisfythe set of requirements.• In general, any ambiguous requirement is not verifiable because it does not useconcrete terms and measurable quantities.• Requirements specification: An SRS is verifiable if, and only if, everyrequirement stated therein is verifiable.Individual requirement: (not applicable to individual requirements).Requirements Specification: An SRS is modifiable if, and only if, its structure andstyle are such that any changes to the requirements can be made easily,completely, and consistently while retaining the structure and style. The structureand style of the requirements are such that any necessary changes to therequirements can be made easily, completely, and consistently. Modifiabilitygenerally requires an SRS to:• Have a coherent and easy-to-use organization with a table of contents, anindex, and explicit cross-referencing;• Not be redundant (i.e., the same requirement should not appear in more thanone place in the SRS);• Express each requirement separately, rather than intermingled with otherrequirements.• Individual requirement: The origin of each requirement is clear and facilitatesthe referencing of each requirement in future development or enhancementdocumentation. The following two types of traceability are recommended:• Backward traceability (i.e., to previous stages of development). Thisdepends upon each requirement explicitly referencing its source in earlierdocuments.• Forward traceability (i.e., to all documents spawned by the SRS). Thisdepends upon each requirement in the SRS having a unique name orreference number.• Requirements Specification: A requirements traceability matrix is generally usedto aggregate traceability of the complete set of requirements to higher-levelrequirements, product design, and test.• Individual requirement: In the knowledge and experience of the evaluator, agiven concept, set of requirements, design, test, etc. violates no knownprinciples or lessons learned that would render it impossible to carry out.• Requirements specification: The set of requirements can be accomplishedwithin cost and schedule and is possible to implement.• Individual requirement: The user and developer communities are able to fullycomprehend a requirement.• Requirements specification: The user and developer communities are able tofully comprehend the aggregate set of requirements.• Conditional: Implies that these arerequirements that would enhance thesoftware product, but would not make itunacceptable if they are absent. Implies aclass of functions that may or may not beworthwhile. This gives the supplier theopportunity to propose something thatexceeds the SRS.• CMMI uses the term “appropriate to implement”Verification methods include:• Test• Inspection• Analysis• Demonstration• Many organizations use testable instead ofverifiable.N/A• Traceability is especially important to ensure thatthe product complied with its own requirements.• Traceability between requirements and testcases is critical to ensuring that the system hasbeen adequately and sufficiently verified (tested)against the set of requirements, demonstratingthat the system functions in accordance with theset of requirements.• Traceability allows the project to handle “what if”questions, such as “What if this requirement ischanged - what is impacted, e.g., design, testcases; and how much the change will cost?”This helps to manage change of the project.• Requirements are achievable by methodsavailable to the project that will supply ordevelop required products or services.• Requirements are operationally feasible and cansatisfy needs and expectations consideringcontext, assumptions, and constraints of theintended environment. Assure feasibility in termsof affordability and risk.• CMMI uses both Feasible and Realizable as 2separate attributes.Figure 8-25. Requirements Attributes Review Checklist. Our checklist provides for a thorough andcomplete review of requirements.N/A8 | 41

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!