DinnerNow WebApp Architecture

WebApp Architecture

DinnerNow Service interface layer & facade classes

Service interface layer & facade classes

DinnerNow Interface & Implementation

DinnerNow Interface & Implementation

DinnerNow layered architecture

layered architecture

DinnerNow Class Design

DinnerNow Class Design from Microsoft

DinnerNow Conceptual design

DinnerNow Conceptual design from microsoft

SRS檢查表

Organization and Completeness

• Are all internal cross-references to other requirements correct?
• Are all requirements written at a consistent and appropriate level of detail?
• Do the requirements provide an adequate basis for design?
• Is the implementation priority of each requirement included?
• Are all external hardware, software, and communication interfaces defined?
• Have algorithms intrinsic to the functional requirements been defined?
• Does the SRS include all of the known customer or system needs?
• Is any necessary information missing from a requirement? If so, is it identified as TBD?
• Is the expected behavior documented for all anticipated error conditions?

Correctness

• Do any requirements conflict with or duplicate other requirements?
• Is each requirement written in clear, concise, unambiguous language?
• Is each requirement verifiable by testing, demonstration, review, or analysis?
• Is each requirement in scope for the project?
• Is each requirement free from content and grammatical errors?
• Can all of the requirements be implemented within known constraints?
• Are any specified error messages unique and meaningful?

Quality Attributes

• Are all performance objectives properly specified?
• Are all security and safety considerations properly specified?
• Are other pertinent quality attribute goals explicitly documented and quantified, with the acceptable tradeoffs specified?

Traceability

• Is each requirement uniquely and correctly identified?
• Can each software functional requirement be traced to a higher-level requirement (e.g., system requirement, use case)?

Special Issues

• Are all requirements actually requirements, not design or implementation solutions?
• Are the time-critical functions identified, and timing criteria specified for them?
• Are all significant consumers of scarce resources (memory, network bandwidth, processor capacity, etc.) identified, and is their anticipated resource consumption specified?
• Have internationalization issues been adequately addressed?

軟體需求與實作追蹤圖 - Traceability

from borland caliberRM

功能流程圖與Scenario by borland caliber

軟體需求定義與管理-Checklist from borland

1. Who owns or is responsible for this requirement?
   
2. What business or user justification is there for this?
   
3. Where is the meaningful discussion for this requirement documented?
   
4. What is its status, priority and feasibility assessment?
   
5. Where is the validation procedure for this requirement?
   
6. Where does this requirement trace to and from enabling quick and
   
7. Has this requirement changed? If so, who changed it, when was it changed, what was changed and why was it changed? How were people notified?
8. accurate requirement change management?
   

exercise:

FR3.2.2.1.5 The system shall be able to identify allocated COTS licenses that will expire within 60 and 120 days. The system shall provide the capability to generate an Expiring License Summary Report that will include a list of the COTS licenses, or associated maintenance agreements, by project/user organization, that will expire in the selected timeframe (either <=60 days, or <=120 days). The list will include the product version/revision, vendor, platform, license expiration date, maintenance agreement expiration date and Point-of-Contact information (name, phone, organization, address, etc.)

軟體需求定義與管理-流程圖

軟體需求種類

Four levels of requirements

• Business requirements describe why the product is being built and identify the benefits for both customers and the business.
• User requirements describe the tasks or business processes a user will be able to perform with the application/product.
• Functional requirements describe the specific system behaviors that must be implemented.
• Non-Functional requirements describe the specific system constraints that must be adhered to by the application/product.

階段工作的錯誤成本

開發工作的典型成本分佈

Planning and management	15%
Analysis/requirements	10%
Design/integration	15%
Implementation/functional tests	30%
Measurement/assessment/acceptance test	15%
Tools/environment/change management	10%
Maintenance (fixes during development)	5%

開發階段的成本與時間

	Inception	Elaboration	Construction	Transition
Effort	5%	20%	65%	10%
Schedule	10%	30%	50%	10%