需求分析筆記 第二章- 需求確定
阿新 • • 發佈:2018-12-18
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
- Flow objects:
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
- Business capability exploration
- 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
- System services → functional 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
- Usability
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
- about specific details
- 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
- Passive
- 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
- Throw-away prototype
- 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
- overlap and conflict
-
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
- Unique identifier (automatically generated)
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
- Glossary