需求分析笔记 第二章- 需求确定

Topics

• From business processes to solution envisioning
• Functional and nonfunctional requirements
• Requirements elicitation
  • traditional methods and modern methods
• Requirements negotiation and validation
• Requirements management
• Requirements business model
  • system scope, business use case model, business glossary, business class model
• Requirements document

---

1.From business processes to solution envisioning

IT solution

• A business solution
• Implementation of a business process
• Sometimes an enabler of business innovation （推动革命）
• An infrastructure service （基础设施）
• A commodity
• IT solutions address （解决）business problems

BPMN - Business Process Modeling Notation

• modeling business processes defined as activities that produce something of value to the organization or to its external stakeholders
• 类似 UML activity diagrams ，OOM
• Process
  • A process may contain other processes (subprocesses)
  • An atomic activity within a process is called a task
• A process hierarchy diagram – not part of BPMN
  • A business process can be performed manually or an automated service
  • A process has at least one input flow and one output flow
  • When the process gains the control, it performs its activity, typically by transforming the input flow into the output flow
  • A process can be atomic or composite

• BPMN flow objects
  • Flow objects:
    • Events
    • Activities
    • Gateways
  • Connecting objects
  • Pools (Swimlanes)
  • Artifacts
    
    

Solution envisioning

• a business value driven approach to delivering an IT service
• Solution envisioning makes a close connection between business and IT stakeholders and integrates business strategy methods and software development capabilities
• about the three “E-s” – efficiency, effectiveness, and edge
• Three phases of solution envisioning process
  • Business capability exploration
    • a business IT solution can deliver specific results.
    • describes capability cases
  • Solution capability envisioning
    • capability case into a solution concept and at ensuring that the solution is agreed upon by the stakeholders
    • The solution concept takes the business context as input and produces future scenarios for new ways to work as output
  • Software capability design
    • Software capability design is an activity in software modeling
• Implementation strategy and capability architecture
  • Custom development
  • Package-based development
  • Component-based development
• 需求分析建立业务过程而不是IT过程。

2.Requirements elicitation

overview

• The least technical phase of system development
• Demands social, communication and managerial skills
• Delivers a (mostly narrative) definition of user requirements

Requirements

• define

  • System services → functional requirements
    • scope of the system
    • necessary business functions
    • required data structures
  • System constraints → nonfunctional requirements
    • regarding ‘look and feel’, performance, security, etc
    • also known as supplementary requirements

• Nonfunctional requirements

  • Usability
    • ease of use , documentation and help, training, user interface, error handling
  • Reusability
    • ease of component reuse
  • Reliability
    • mean time between failures, graceful recovery, uninterrupted availability, accuracy of results
    • reliable = dependable (we can depend on it)
  • Performance
    • response time, transaction throughput, resource consumption, concurrency level
  • Efficiency
    • in terms of time and cost
  • Supportability
    • understandability + maintainability + scalability
  • Other constraints
    • policy decisions, legal issues, portability and interoperability demands, timeliness of product delivery

3 Requirements elicitation methods

Traditional methods of requirements elicitation

• overview
  • Simple and cost effective
  • When clear objectives and low project risks
  • Include:
    • Interviewing customers and domain experts
    • Questionnaires
    • Observation
    • Study of documents and software systems
• Interviewing customers and domain experts
  • With customers – mostly use case reqs
  • With domain experts – frequently a straight knowledge transfer
  • Structured (formal) interview
    • Open-ended questions (unanticipated responses)
    • Close-ended questions (a list of possible responses known)
  • Unstructured (informal) interview (no prepare questions)
  • Questions to be avoided
    • Opinionated questions (do we have to do things the way we do them?)
    • Biased questions (you are not going to do this, are you?)
    • Imposing questions (you do things this way, don’t you?)
  • Summary report of the interview should be sent to the interviewee within a day or two, along with a request for comments
• Interview – kinds of questions
  • about specific details
    • five Ws: what, who, when, where, and why
  • about vision for the future
  • about alternative ideas
    • these may be questions to an interviewee and suggestions from the interviewer asking for opinions
  • about minimally acceptable solution to the problem
    • good usable systems are simple systems
  • about other sources of information
    • can discover important documents and other knowledge sources unknown before to the interviewer
  • soliciting diagrams
    • drawn by an interviewee to explain business processes may prove invaluable for understanding the requirements
• Questionnaires
  • In addition to interviews
  • A passive technique
  • Close-ended questions
• Observation
  • In addition to interviews (and possibly questionnaires)
  • Three forms
    • Passive
      • no interruption or direct inmvolvement
      • video camera may be used
    • Active
    • Explanatory
      • explaining what is done when observed
    • Should be carried for a prolonged time, at different times and at different workloads
    • People tend to behave differently when watched
• Study of documents and software systems
  • Study of documents and software systems
  • Use case requirements
  • Domain knowledge requirements

Modern methods of requirements elicitation

• overview
  • Offer better insights at higher cost and effort
  • When high project risks (unclear objectives, undocumented procedures, unstable requirements, eroded user expertise, inexperienced developers, insufficient user commitment, etc.)
  • Include:
    • Prototyping
    • Brainstorming
    • Joint Application Development (JAD)
    • Rapid Application Development (RAD)
• Prototyping
  • ‘Quick and dirty’ solution to obtain feedback
  • Necessary in complex and innovative projects
  • Two kinds:
    • Throw-away prototype
      • targets requirement determination
    • Evolutionary prototype
      • targets the speed of product delivery
• Brainstorming
  • to form new ideas or to find a solution to specific problem
  • not to solve a problem
• JAD 联合应用开发
• RAD 快速应用开发
  • Evolutionary prototyping
  • CASE tools
  • Specialists with Advanced Tools (SWAT)
  • Interactive JAD
  • Timeboxing no ‘scope creep’, timeboxed project
  • Problems
    • suitable for smaller projects; too risky for larger developments

4 Requirements negotiation, validation and management

overview

• elicited requirements need to undergo careful negotiation and validation with all stakeholders
• requirements identification and classification
• requirements hierarchies
• change management
• requirements traceability

Requirements negotiation and validation

• reason

  • overlap and conflict
    • requirements dependency matrix
  • may be ambiguous or unrealistic
  • may remain undiscovered
  • may be out of scope

• frequently done in parallel with requirements elicitation

• requirements dependency matrix

  • 需求标识并标号
  • 独立，重叠 ，矛盾

• Requirements risks and priorities

  • Risk is a threat to the project plan
  • Risks determine project’s feasibility
  • Risk analysis identifies requirements that are likely to cause development difficulties
  • Prioritization is needed to allow easy rescoping of the project when faced with delays
  • Risk categories
    • Technical
    • Performance
    • Security
    • Database integrity
    • Development process
    • Political
    • Legal
    • Volatility

Requirements identification and classification

• Natural language statements
  • The system shall schedule the next phone call to a customer upon telemarketer’s request.’
• Identification and classification scheme
  • Unique identifier (automatically generated)
    • database generated, if possible
    • including version number, if possible
  • Sequential number with document hierarchy
    • the seventh requirement in the third section of the second chapter would be numbered 2.3.7
  • Sequential number with requirement’s category
    • where the categories of requirements can be: function requirement, data requirement, performance requirement, security requirement, etc

Requirements hierarchies

• Requirements hierarchies
• 1 ，1.1 ，1.1.1

Change management

• A requirement may change, be removed, or a new requirement may be added
• Downstream cost of change
• Strong management policies needed to
  • document change requests,
  • to assess a change impact
  • and to effect the changes
• Requirements changes should be stored and tracked by a software configuration management tool

Requirements traceability

• A critically important part, of change management
• A suspect trace – after change to any element in a traceability relationship

5. Requirements business model

overview

a high-level visual representation of elicited, negotiated and validated requirements

• 需求文档 ：有什么需求
• 规格说明书：需求是什么
• 需求business model 不等于 UML
  

系统范围

• Context diagram
  
  

Business use case diagram

• 不同于UML的use caes
• 业务用例可能是系统完成，也可能是手工完成
• 除了关联，不使用UML中的关系

Business glossary

• 词汇表
• Term
• definition

Business class diagram

• 关联(asssociation)， 泛化，聚合（aggregation）
• association 特性：重数 和参与
• aggregation是更强的assocatin

6. Requirements document

• a tangible outcome of the requirements determination phase
  

Project preliminaries

• Targets managers and decision makers
• Begins with purpose and scope of the project
• Makes a business case for the system
• Identifies stakeholders
• Offers initial ideas for the solution
  • including off-the-shelf solutions
  • off-the-shelf does not dispense with the need for RASD
• Includes an overview of the rest of the document

System services

-definition of system services - what the system must accomplish

• 核心部分，account for more than half of the entire document
• Contains high-level requirements business models
  • Context diagram (the system scope)
  • Business use case diagram (function requirements)
  • Business class diagram (data requirements)
    • main attributes, but no operations
  • Business glossary moved to the Appendix

System constraints

• Interface requirements
  • ‘look and feel’ only
• Performance requirements
  • response times, but also reliability, availability, throughput indicators
• Security requirements
  • access privileges
• Operational requirements
  • hardware/software environment
• Political and legal requirements
• Other constraints
  • usability
  • maintainability

Project matters

• Open issues
  • Future requirements
  • Current requirements to be implemented in the future – enhancements
  • Potential problems when the system is deployed
• Preliminary schedule
  • Human and other resources
  • Planning charts (PERT, Gantt)
• Preliminary budget
  • Project cost – range rather than figure
  • In some cases, better estimation possible (e.g. function point analysis)
• Appendices
  • Glossary
    • Terms
    • Acronyms
    • Abbreviations
  • Documents and forms
    • Examples of completed (filled in) forms
  • References
    • To books and other published sources
    • Meetings’ minutes, memoranda, internal documents