Please enable JavaScript.

Coggle requires JavaScript to display documents.

Kravhantering (Funktionella och icke funktionella krav (Icke-funktionella…

- - - - Produkt req
        
        Requirements which are a consequence of organisational
        policies and procedures e.g. process standards used,
        implementation requirements, etc.
      - Organisationell req
        
        Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.
      - external req
        
        Requirements which specify that the delivered product must
        behave in a particular way e.g. execution speed, reliability, etc.
      - OLIKA Icke - funktionella (nonfucntional) requirement
        
        Hastighet (speed)
        
        Storlek
        
        Ease of use
        
        tränings tid och hjälp som användarna får för att kunna använda systemet
        
        tillförlitlighet (reliability)
        
        Robusthet
        
        Time to restart after failure
        Percentage of events causing failure
        Probability of data corruption on failure
        
        Portability (flyttbarhet)
        
        svårt att överföra mål till mätbara krav.
- - - - This should define the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader.
    - - you describe the services provided for the user. The nonfunctional system requirements should also be described in this section. This description may use natural language, diagrams, or other notations that
        are understandable to customers. Product and process standards that must be followed should be specified.
    - - This should describe the need for the system. It should briefly describe the system’s functions and explain how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software.
    - - present a high-level overview of the anticipated
        system architecture, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted
    - - This should define the expected readership of the document and describe its version history, including a rationale for the creation of a new version and a summary of the changes made in each version.
    - - This should describe the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements.
        Interfaces to other systems may be defined.
    - - This might include graphical system models showing the relationships between the system components and the system and its environment.
    - - This should describe the fundamental assumptions on which the system is based,and any anticipated changes due to hardware evolution, changing user needs,
        and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system.
    - - These should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions.
        Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used
        by the system and the relationships between data.
    - - Several indexes to the document may be included. As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, and so on. (register)
- - - - Olika beroende på application domain, människor involverade och organisations utvecklings req
        
        General activities that are interleaved
        
        Analysis
        
        Requirements Validation
        
        Concerned with demonstrating that the requirements
        define the system that the customer really wants.
        
        Requirements error costs are high so validation is very
        important
        
        Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.
        
        Requirements checking
        
        Validity. Does the system provide the functions which
        best support the customer’s needs?
        
        Consistency. Are there any requirements conflicts?
        
        Completeness. Are all functions required by the
        customer included?
        
        Realism. Can the requirements be implemented given
        available budget and technology
        
        Verifiability. Can the requirements be checked?
        
        Requirements validation techniques
        
        Requirements reviews
        
        Systematic manual analysis of the requirements.
        
        Prototyping
        
        Using an executable model of the system to check requirements. experimentera
        
        Test-case generation
        
        tester som kollar om de uppfyller kraven
        
        Ultimately, it is difficult to show that a set of requirements does in fact meet a user’s needs. Users need to picture the system in operation and imagine how that system
        would fit into their work. It is hard even for skilled computer professionals to perform this type of abstract analysis and harder still for system users. As a result, you rarely find all requirements problems during the requirements validation process.
        
        Elicitation, discovery
        
        SW engineers work with customers and end users to find out about what services the system should provide, req performance, HW osv.
        
        Steg som ingår requirement-
        
        classification and organization
        
        1 more item...
        
        prioritization and negotition
        
        1 more item...
        
        Discovery
        
        3 more items...
        
        Requirements Specification
        
        5 more items...
        
        Scenarios and use cases are effective techniques for eliciting requirements from stakeholders who interact directly with the system. Each type of interaction can be represented as a use case.
        
        May involve end-users, managers, engineers involved in
        maintenance, domain experts, trade unions, etc. These
        are called stakeholders.
        
        Iterativ
        
        Problem:
        
        Intressenter vet inte alltid vad de vill ha
        
        express requirements in their own terms.
        
        Different stakeholders may have conflicting
        requirements.
        
        Organisational and political factors may influence the
        system requirements. icke funktionella
        
        The requirements change during the analysis process.
        New stakeholders may emerge and the business
        environment may change
        
        Ethnography
        
        A social scientist spends a considerable time observing
        and analysing how people actually work.
        
        People do not have to explain or articulate their work. svårighet att beskriva också
        
        Social and organisational factors of importance may be
        observed.
        
        Ethnographic studies have shown that work is usually
        richer and more complex than suggested by simple
        system models.
        
        Hur man tillämpar Ethnography på krav inhämtning
        
        Requirements that are derived from the way that people
        actually work rather than the way I which process
        definitions suggest that they ought to work.
        
        Krav som härstammar från samarbeten och kännedom om människors aktiviteter
        
        1 more item...
        
        OBS!
        
        1 more item...
        
        Komplement till krav insamling
        
        Bra att kombineras med prototyp.
        
        Problem:
        
        The problem with ethnography is that it studies existing
        practices which may have some historical basis which is
        no longer relevant.
        
        Management, förvalta req förändringar nya som gamla system.
- - - - Of services of a system
      - or constraints
    - - may be basis for a bid for a contract, must be open to interpretation
        
        User requirements
        
        Natural language, what service system rpovides and its operational constraints. basic written for customers
        
        Läsare som, client managers, system end-users, client engineers, cranctor managers, system achitectrs.
      - may be the basis for the contract itself- therefore must be defined in detail.
        
        System requirements
        
        strukturerat dokument med detaljerad beskrivning av system funktionerna, service, funktionella restriktioner. between client and contractor. Som ett kontrakt.
        
        Läsare som, system endusers, client (beställare/kund) engineers, system architect, sw developers.
      - se s 101 för bild på skillnad (bok) s7 pp.
- - - - User stories funkar ej för kritiska system som kräver föranalyser och utecklas av flera team. endast bizznizz system (enkla)
- - - - Mål (goals) är bra för utvecklare för att de förmedlar system användarnas avsikter.