Software Engineering Terms Collection 1

Abstraction

This note collect all terms occur in SEPP Lecture 1/2/4/5. It would be helpful to recap what has learnt and what has already been abstracted away.

Pool of atomic terms

small system, budget, reliability, complex interface, software development, requirement capture, design, construction, implementation, testing, debugging, maintenance, evolution, management, software engineering activity

needs, issues, stakeholder, prioritization, maintenance, evolving requirement, modelling language, UML, multiple level, architectural design, high-level design, detailed design, coding, unit test, code evolution, documentation, customer acceptance testing, cost, post release change, enhancing, coping with changing world, maintainability

ordering activities, outcomes of activities, arrangement of people & resources, planning in advance of execution, predicting cost/time/resources, risk reduction, monitoring, enabling their own adaptation

automating, business process, project based engineering, product based engineering, execution model, software product, stand-alone model, hybrid execution model, software as a service model, reusable software

waterfall process, linear sequential life cycle model, plan-driven process, plan, change, unchangeable world, stage, safety system, embedded system, long lifetime system

agile process, iteration of development, testing the software development process, communication, customer, developer, manager, tester, motivated individual, customer collaboration, unfinished features, most important features, iterative planning, honest plan, daily communication, working software

customer satisfaction, rapid delivery, principal measure of progress, daily co-operation, face-to-face conversation, continuous attention, technical excellence, good design, simplicity, self-organizing team, regular reflection on process, regular reflection on tuning of behaviour

high/low criticality, senior/junior developer, culture, order, culture that responds to change, culture that demands order

software requirement, organisation, requirements engineering, systematic handing of requirement

functional requirements, non-functional requirements, ‘ilities’, efficiency, security, portability, usability, user experience, distinction

person, group, end user, customer paying for software, government regulator, system architect, software developer, software tester

elicitation, analysis, specification, validation, strict sequence, project failure

elicitation source, goal, domain knowledge, business rule, operational environment, organizational environments, interview, scenario, prototype, facilitated meeting, observation, conflict, single consistent set of requirement, careful structured English, use case model, supporting text, formal specification, mathematically-based language, release, consistency check, completeness check, realism check, verifiability, measurable non-functional requirement

use case, system’s behaviour, user, viewpoint of user, unit, coherent unit of functionality, actor, human user, external system, external device, further information, primary actor, messages, supporting actor, use case scenario, instance, guarantee, main success scenario, alternate success scenario, failure scenario, common user goal, trigger, pre-condition, assumption, stick figure, named oval, interaction, requirement specification, iterated requirement elicitation

graphical language, UML model, model-driven development, granularity, abstraction

Key linkage between atomic terms

1. waterfall model process which is also known as liner sequential life cycle model.
2. in agile process, development and testing activities are concurrent
3. software development process is description of how different engineering tasks are ordered, planned and monitored.
4. maintenance is the art to manage evolving requirements.
5. project based engineering is based on customer.
6. product based engineering is based on developer, or the developer is the customer.
7. plan-driven process is not easy to make change.
8. waterfall model has no way go back to some previous stage.
9. agile process is able to react quickly to change.
10. working software is the principal measure of progress
11. the term order is the opposite to change.
12. requirement try ot avoid design.
13. requirement expressing what is desired, not how what is desired should be realized.
14. non-functional requirements may be more important than functional requirements.
15. distinction between non and functional requirements may not clear.
16. stakeholders are “any person or group who will be affected by the system, directly or indirectly”.
17. faulty requirement processes is the major source of project failure.
18. a user is anything external to the system which interacts with it.
19. actors are a kind of user who take an active part in the use case.
20. some stakeholders may be neither primary nor supporting actors.
21. a use case is a set scenario tied together by a common user goal.
22. in use case diagram, the line connecting different actors or use cases means possible interaction between them.
23. use cases primarily capture functional requirements, but sometimes non-functional requirements are attached to a use case.
24. in use cases diagram, interactions spelled out may be too detailed, may needlessly constrain design.
25. in use cases diagram, requirements not naturally associated with actors may be missed. (those automatically triggered by the system)

Rule to categorize atomic terms

1. How close they link with others.
2. Are they belong to some existing categories.
3. No need to explicitly classify all these terms into different groups.

Unfamiliar terms

enabling their own adaptation, regular reflection, tuning of behaviour