1. Home
  2. How To Dev - Analysis Phases

How To Dev - Analysis Phases

×

Warning message

You can't delete this newsletter because it has not been sent to all its subscribers.

 

Development Life Cycle

    Analysis: phase in which the comprehension of the problem/subproblem, extraction of requirements and definition of the main elements for the specification is performed.

    Please take in mind that the analysis can be performed by subsystems or just incremental for adding new features to your former solution (previous Sprint or actually legacy solution). Thus, you do not be afraid to produce since the first-round a full set of exhaustive requirements, or scenarios, or use cases. We suggest you, at the first sprint to focus on the most relevant aspects and start design them and develop the prototype with those elements only in the first sprint.

    The main activities of the Analysis Phase are:

    • workshops and discussions on the track of Innovation Matrix by domain, and Entity identification
    • production of the Dictionary via entity identification: physical, virtual and modules/tools
    • Scenarios formalization
    • Use Cases formalization
    • Requirements formalization
    • Sequence Diagrams formalization, for the most relevant aspects
    • This phase should answer at questions such as:
      • What the solution/task should do?
      • What the users/entities are expecting to get from the solution/task?
      • Who is going to use the solution/task?
      • How many users/entities are going to use it at the same time?
      • Which is the most preferred modality to interact?
      • Which are the most effective representations of results?
      • When is it going to be used?
      • Which are the KPI to confirm that the development has reached the goals?
      • …

    This phase is successfully performed by:

    • Performing workshops for Innovation Matrix by domain: mobility, energy, parking, gov services, etc. (see the image below).
    • Entity Identification: which is the Dictionary to be used into the Use Cases and Scenarios. Classic entities and specialized entities are respectively as follows. The entities are the major data and actors in the description coming from the workshop for the Innovation Matrix. Example of entities could include:
      • Actors and their profiles (as Data Models): User, Operator, final user, ICT expert, decision maker, doctors, driver, etc.
      • Entity Models:
        • Entities and their digital counterpart (Data Models) for: Vehicle, Analysis, Server, Client, Mobile App, parking area, etc.
        • Actors are modeled as Entity Model if they need to be represented into the system.
      • Entity Instances:
        • IoT Devices which are instances of the models as: City user XX, Control Room Operator, Doctor Rossi, Cop 3726, Car FI796HG, IoT Device XY, Trip 34, Patient Health Record for Robert, etc.
      • Modules or Tools of Third party or legacy tools:  they are applications, servers, IoT Edge subsystems, well known services for data providing, gateway, brokers, etc., which should interact somehow with your solutions. They can be on cloud or on some premise, they can provide you some External API, of some kind: WebServices, Rest Call, FTP, Web Socket, MQTT, etc.
        • Tools: which can be actual software or hardware tools, and also data analytics, algorithms, procedures.
      • External Services/Tools/API which can be provide by third parties. They can be HW/SW tools to interoperate with Modules and among each other. For example, external brokers, gateways, third party APIs, etc. 
        • External API: to interoperate with any other application and service.
        • External Services: to host into the user interface and Dashboards elements coming from third party applications.
    • Scenarios Formalization describing the application/task, textual definition, with some standard table as UML. The scenarios have to refer to identified entities.
    • Use Cases Formalization describing the different cases into the single applications, by using UML formalization, there are specific Use Cases for each Scenario. Please focus on the most relevant, those that are adding value to your solutions. The others can be given for granted in a first phase.
    • Requirements Formalization and elicitation via workshops and documents analysis by using standard tables, prioritizing them, setting mandatory/preferred/optional, functional and non-functional, first/second/third release, etc.
    • Sequence/Activity Diagrams Formalization: to highlight some of the critical aspects. For example, to describe the user interaction, and/or the interaction among main entities, putting in evidence which is the Entity starting the dialogue with respect to the others involved (e.g., a client requesting data to the server, a device sending data to the broker). UML sequence diagrams are a suitable formalization for the purpose.

     

    • Share