System development

24 important questions on System development

What is the purpose of the initial sketch?

One way to make the communication easier between the developer, commissioner and end-user is the initial sketch. The purpose of this is that you already make it visible what the system would be able to do, even without having written any software itself. This early agreement is later used to build

How can use case diagrams assist with software development?

Use cases can help in the early stages to systematically record the (hidden) system requirements by writing down "use cases": ways of using the system.

What are the purposes of use cases?

  • Generate new requirements as the design takes shape
  • Communicate with stakeholders
  • Generate the test cases
  • Higher grades + faster learning
  • Never study anything twice
  • 100% sure, 100% understanding
Discover Study Smart

What are the typical requirements for common stakeholders?

  • End user - usability, performance
  • Sponsor - performance (more in the form of scalability)
  • Data owner - integrity, availability
  • Regulator - confidentiality, integrity, auditability

Which kinds of requirements are there?

  • Functional requirements
  • Non-functional requirements
  • Constraints
  • Project issues

What are functional requirements?

Actions that the system should perform. Can be assigned to individual components of the system. E.g. Reservation system should indicate how many tickets for a performance are available

What are non-functional requirements?

General properties the system should have (e.g. performance, security, reliability, usability). Applies to the system as a whole. E.g. reservation system should be adequately protected  to secure customer data

What are project issues?

Ask assignment, resources, planning, budget
E.g. the system is operational by 1st of May, 2017

What are three recommendations to improve ICT projects for the government? According to Elias committee?

  • 2. Demonstrate added value of project for end users and for society.
  • 3. Create support among all parties involved, including end-users, and test for organizational, administrational and technical feasibility.
  • 10. Make use of a transparent bid-for-tender strategy in the business justification of a project (PID) – Project Initiation Document, very clear description of the purpose and goal of a project
    • b. make functional specification compulsory, or explain why not. Specific technical details are left to the provider.  

In general: professional commissioning [ NL: opdrachtgeverschap]

In general, which types of feasibility are there?

  • Organizational feasibility: does it fit the current governance structure
  • Administrational feasibility: does it fit the capabilities of the ministry
  • Technical feasibility: does it connect to existing systems that you need to work with

Explain bid-for-tender strategy

Bid-for-tender strategy refers to the demand by law that all big governments projects should be offered on the market under a bid-for-tender. That means numerous different providers can subscribe and do a bid where typically the best one should win. In other words, the cheapest one that can deliver the most functionality. However if it is unclear what the software development would involve, then this is a unfair comparison. If there is a lot of space for interpretation then just the cheapest would win, but later it turns out that what they offer is rather insufficient.

Explain the requirements engineering 'joke'

Before you build something, you can't indicate what it is what you want, because you can't visualize it. Software is very abstract.
Example: swing

Explain 'design as a dialogue'

The developer knows the domain, but doesn't knows the customer needs. Customer has needs, but doesn't know what the system wants from them.
  • Sense-making, interpretation, negotiation
  • Rapid-prototyping; iterative development; trying out real versions of the product

What ar the inherent properties of software development?

1. Complexity
2. Conformance
3. Changeability
4. Visibility

What kinds of complexity are distinguished in the paper of Brooks (1987)?

Essence: difficulties inherent in nature of problem to be solved
Accidents: difficulties we have created

Explain the property changeability (later linked to uncertainty)

Unlike manufactured things, software can and must be changed also after production (updates)
Pressure of change, comes from people who invent new uses, and software survives beyond the machine for which it is first written

How does Brooks address the issues regarding the inherent properties?

  • Remove accidental difficulties
  • Address conceptual essence

How to address complexity?

  • Loosely coupled architecture
    • Less dependencies
    • Local decision making
  • Centralize
    • From O(n2) to O(n) connections
    • Single point of failure
  • Standardization
    • System of systems
    • Interoperability: syntax (form), semantics (meaning), pragmatics (use)
  • Re-use
    • Buy or build
    • Libraries: task models; domain models
  • Organizational learning

What does not work when dealing with complexity, and why?

Adding manpower to a late software project makes it later
Why?
  • New project members need to learn, because software project are complex. This takes existing resources away from development
  • An increase in staff drives communication overhead, including the number and variety of communication channels.

What is the difference between verification and validation?

  • Verification: test if the system was built right
    • i.e. according to requirements
    • Formal verification: prove specification properties; walkthrough
  • Validation: test if the right system was built
    • i.e. according to stakeholder needs and environment
    • user experiments; expert interview; acceptance test

What is the definition of requirements engineering?

Discipline to 'capture, share, represent, analyze, negotiate , and prioritize requirements as a basis for design decisions and interventions'

Requirements engineering involves which three facets?

1. Discovery
2. Specification
3. Validation and verification

What are the challenges regarding requirements engineering?

  1. Multiple concepts of design and its intertwining with requirements.
  2. Evolution and management of requirements under growing complexity.
  3. Architectural implications and platform strategies.
  4. Identification of changing stakeholder roles and management challenges in handling stakeholder arguments around RE.

What are the four principles as mentioned in the paper of Jarke et al. (2011)?

1. Intertwine requirements with organizational/ business context
  • Problem and solution interaction during evolution (co-creation)
2. Evolution of requirements
  • Evolve incomplete designs: allow flexibility
3. Architectures as a critical stabilizing force
  • architectures have variation points that influence evolution
  • Transfer of product lines to the software field
  • Possibility or desirability of a single common ontology?

4. Recognize unprecedented levels of design complexity
  • Non-linear behavior, whole is different from sum of its parts
  • (1) make requirements selection process self-organizing
  • (2) traceable process, so designers can follow rate of change

The question on the page originate from the summary of the following study material:

  • A unique study and practice tool
  • Never study anything twice again
  • Get the grades you hope for
  • 100% sure, 100% understanding
Remember faster, study better. Scientifically proven.
Trustpilot Logo