Requirements Elication

• the application domain

• the servie and operational contraints

• (system performance, hardware constraints, etc.)

• end users, managers, engineers involved in maintenance

• domain experts, trade unions, etc.

• these are called stackholders

1. Requirements Discovery

2. Requirements Classification and Organization

3. Requirements Priorization and Negotiation

4. Requirements Specification

Interacting with stakeholders to discover their requirements

Groups related requirements and organises them into coherent clusters

Prioritising requirements and resolving conflicts

Requirements are documented and input into the next round

• stakeholder dont know what they really want

• stakholder express requirements in their own terms

• different stakeholders may have conflicting requirements

• oranisational and political factors may influence the system requirements

• the requirements change during the analysis process

  • new stakeholders may emerge and the business environment change

• to gather informations about the required and existing systems and distil the user and system requirements from this infromation

• main concerns:

  • stakeholder

  • discovery techniques/approaches/…

  
  

• decide on eliciation scope and agenda

• prepare resources

• prepare questions and straw man models

Perform eliciation sessions

• organize and share notes

• document open issues

• part of most RE processes

• type of interview: closed vs open -> mixed?

• be effectiv

• be open minded, avoid pre-conceiveed ideas about the requirements and are willing to listen to stakeholdern

• prompt the interviewee to get discussiosn going using a springboard question, a requirements proposal, or by working together on a prototype system

• approach and modeling method to

  • identify goals and sub goald of software systems

  • identify who and how to achieve the goals

  • identify domain hypothesis and conflicts

• similar principle to use cases and user stories

• can be applicable to cyber-physical systems and user systems interaction systems

• initial goal identification

• elicating new goals through WHY and HOW questions

• identifying agents and responsibility assignments

• identifying operations

• anticipating obstacles

• identifying domain hypothesis

• handling conflicts

• an objective the system under consideration should achieve

• goal is condition or situation that can be achieved or not

• goal is used to define the functional requierements of the system

• goal provide a precise criterion fir sufficients completeness of a requirements specification

• satisfaction cannot be established in a clear-cut sense

• useful for comparing alternative goal refinements

• improve

• maximise/minimise

• icrease/reduce

satisfaction can be establishes through verification

• achieve/cease

• maintain/avoid

achieve: some targete property to be eventually satisfied

maintain: some targete property to be permanently satisfied

avoid: some targete property to be peramantetly denied

each sub goal is refined into finer grained goals until we reach a software requirements associated with a single agent and expectation (assumption) on the evironment