GROUP 3

DFP5043 – Software Requirement and Design

Tutorial Lab5

CLO2

Instruction:

Discuss and contribute together to answer  

the questions below and post the answer to the class’s blog.

Don’t forget to write your name in the blog.

Q1. Discover ambiguities or omissions in the following statement of

requirements for part of a ticket-issuing system:

An automated ticket-issuing system sells rail tickets. Users select their

destination and input a credit card and a personal identification number.

The rail ticket is issued and their credit card account charged. When the user

presses the start button, a menu display of potential destinations is

activated, along with a message to the user to select a destination. Once a

destination has been selected, users are requested to input their credit card.

Its validity is checked and the user is then requested to input a personal

identifier. When the credit transaction has been validated, the ticket is

issued.

Answer:

Ambiguities and omissions include:

1. Can a customer buy several tickets for the same destination together or must

they be bought one at a time?     

2. Can customers cancel a request if a mistake has been made?

3. How should the system respond if an invalid card is input?

4. What happens if customers try to put their card in before selecting a

destination (as they would in ATM machines)?

5. Must the user press the start button again if they wish to buy another ticke

to a different destination?

6. Should the system only sell tickets between the station where the machine is

situated and direct connections or should it include all possible destinations?

Add 3 more answer.

7. Can the system provides other languages?

8. Is the system understandable by customers?

9. Does the system provides data security?

Q2. Write a set of non-functional requirements for the ticket-issuing system,

setting out its expected reliability and response time.

Answer:

Possible non-functional requirements for the ticket issuing system include:

1. Between 0600 and 2300 in any one day, the total system down time should

not exceed 5 minutes.

2. Between 0600 and 2300 in any one day, the recovery time after a system

failure should not exceed 2 minutes.

3. Between 2300 and 0600 in any one day, the total system down time should

not exceed 20 minutes.

4. After the customer presses a button on the machine, the display should be

updated within 0.5 seconds.

5. The ticket issuing time after credit card validation has been received should

not exceed 10 seconds.

6. When validating credit cards, the display should provide a status message

for customers indicating that activity is taking place.

7. The maximum acceptable failure rate for ticket issue requests is 1: 10000.

Add 3 more answer.

8. The minimum acceptable success rate for the ticket issue request is 1:1

9. At the ticket confirmation, pop up messages will be given for a minute.

10. The time for ticket to be print should not exceed 1 minute.

By:

MOHAMMAD HUZAIFAH BIN MOHAMED YUSOFF (01DDT17F1007)

LUKMAN HAKIM BIN MAMAT (01DDT17F1001)

MOHAMMAD AMIRUL SHAH BIN MOHAMAD NASIR (01DDT17F1021)

MUHAMMAD ALIF BIN ZAKARIA (01DDT17F1014)

AHMAD FITRI BIN AHMAD (01DDT17F1006)

AHMAD LUQMAN BIN ADAM (01DDT17F1009)

MUHAMAD AFIQ FAHMI BIN JINS (01DDT17F1027)

Functional and Non-Functional Requirements (Group 4)

DFP5043 – Software Requirement and Design

Tutorial Lab5

CLO2

Instruction:

Discuss and contribute together to answer the questions below and post the answer to the class’s blog. Don’t forget to write your name in the blog.

Q1. Discover ambiguities or omissions in the following statement of requirements for part of a ticket-issuing system:

An automated ticket-issuing system sells rail tickets. Users select their destination and input a credit card and a personal identification number. The rail ticket is issued and their credit card account charged. When the user presses the start button, a menu display of potential destinations is activated, along with a message to the user to select a destination. Once a destination has been selected, users are requested to input their credit card. Its validity is checked and the user is then requested to input a personal identifier. When the credit transaction has been validated, the ticket is issued.

Answer:

Ambiguities and omissions include:

1. Can a customer buy several tickets for the same destination together or must they be bought one at a time?   

2. Can customers cancel a request if a mistake has been made?

3. How should the system respond if an invalid card is input?

4. What happens if customers try to put their card in before selecting a destination (as they would in ATM machines)?

5. Must the user press the start button again if they wish to buy another ticket to a different destination?

6. Should the system only sell tickets between the station where the machine is situated and direct connections or should it include all possible destinations?

Add 3 more answer.

7. Can customers change their destination after bought the ticket?

8. What will happen if user repeatedly enter invalid combination of username and password?
9. How can customers contact customer support hotline if there is any enquiries?

Q2. Write a set of non-functional requirements for the ticket-issuing system, setting out its expected reliability and response time.

Answer:

Possible non-functional requirements for the ticket issuing system include:

1. Between 0600 and 2300 in any one day, the total system down time should not exceed 5 minutes.

2. Between 0600 and 2300 in any one day, the recovery time after a system failure should not exceed 2 minutes.

3. Between 2300 and 0600 in any one day, the total system down time should not exceed 20 minutes.

4. After the customer presses a button on the machine, the display should be updated within 0.5 seconds.

5. The ticket issuing time after credit card validation has been received should not exceed 10 seconds.

6. When validating credit cards, the display should provide a status message for customers indicating that activity is taking place.

7. The maximum acceptable failure rate for ticket issue requests is 1: 10000.

Add 3 more answer.

8. When user entered invalid combination of username and password, the display should provide a status message for customers indicating there is an error.

9. When entering user’s information, the display must provide an error handling to avoid invalid format of email or phone number.

10. How efficient is the access and response time for customer to connect with the system?

NAME:

• Nazaratul Kasrina binti Kamarulzaman (01DDT17F1011)

• Nurul Adlina Binti Muhamad Zainal (01DDT7F1019)

• Anis Wahida Binti Razik (01DDT17F1020)

• Siti Nur Mariah Binti Abdullah (01DDT17F1030)

• Muhamad Aidil Irfan bin Ahmad Azali (01DDT17F1028)

• Mohammad Aizat Nazmi bin Mohd Satar (01DDT17F1034)

• Azrul Faiz bin Abd Aziz (01DDT17F1029)

• Mohammad Raihan bin Mohd Johari (01DDT17F1031)

GROUP 2: Ambiguities or omissions and non-functional requirements for the ticket-issuing system

Q1. Discover ambiguities or omissions in the following statement of

Requirements for part of a ticket-issuing system:

An automated ticket-issuing system sells rail tickets. Users select their destination and input a credit card and a personal identification number.

The rail ticket is issued and their credit card account charged. When the user

Presses the start button, a menu display of potential destinations is

activated, along with a message to the user to select a destination. Once a

destination has been selected, users are requested to input their credit card.

Its validity is checked and the user is then requested to input a personal

identifier. When the credit transaction has been validated, the ticket is

issued.

Answer:

Ambiguities and omissions include:

1. Can a customer buy several tickets for the same destination together or must

they be bought one at a time?

                                                  

2. Can customers cancel a request if a mistake has been made?

3. How should the system respond if an invalid card is input?

4. What happens if customers try to put their card in before selecting a

destination (as they would in ATM machines)?

5. Must the user press the start button again if they wish to buy another ticket

to a different destination?

6. Should the system only sell tickets between the station where the machine is

situated and direct connections or should it include all possible destinations?

7. Can customer buy multiple ticket using the same user card (discount card)?

8. Can customer change the ticket before ticket become invalid?

9. Can counter ticket provide the same ticket if the customer lost their ticket?

Q2. Write a set of non-functional requirements for the ticket-issuing system,

setting out its expected reliability and response time.

Answer:

Possible non-functional requirements for the ticket issuing system include:

1. Between 0600 and 2300 in any one day, the total system down time should

not exceed 5 minutes.

2. Between 0600 and 2300 in any one day, the recovery time after a system

failure should not exceed 2 minutes.

3. Between 2300 and 0600 in any one day, the total system down time should

not exceed 20 minutes.

4. After the customer presses a button on the machine, the display should be

updated within 0.5 seconds.

5. The ticket issuing time after credit card validation has been received should

not exceed 10 seconds.

6. When validating credit cards, the display should provide a status message

for customers indicating that activity is taking place.

7. The maximum acceptable failure rate for ticket issue requests is 1: 10000.

8. Ticket must be printed out in less than 1 second after validating credit card.

9. The time taken for receipts to be printed out should not exceed 1 second.

10. The maximum acceptable failure rate for transaction requests is 1:10000.

POST BY:

NOOR SUFIATUL ASNI (1054)
FARAH NADIAH (1062)
NURATUL AIN (1052)
SITI HAJAR (1044)
MIMI AMIRAH (1045)
INSYIRAH (1039)
NADIAH (1098)
FAIZAH (1036)
ARINAH (1059)
FILZAH (1060)
ATHIRAH (1043)

Functional and Non-Functional Requirements (Group 1)

DFP5043 – Software Requirement and Design

Tutorial Lab5

CLO2        

Instruction:

Discuss and contribute together to answer  

the questions below and post the answer to the class’s blog.

Don’t forget to write your name in the blog.

Q1. Discover ambiguities or omissions in the following statement of

requirements for part of a ticket-issuing system:

An automated ticket-issuing system sells rail tickets. Users select their

destination and input a credit card and a personal identification number.

The rail ticket is issued and their credit card account charged. When the user

presses the start button, a menu display of potential destinations is

activated, along with a message to the user to select a destination. Once a

destination has been selected, users are requested to input their credit card.

Its validity is checked and the user is then requested to input a personal

identifier. When the credit transaction has been validated, the ticket is

issued.

Answer:

Ambiguities and omissions include:

1. Can a customer buy several tickets for the same destination together or must

they be bought one at a time?     

2. Can customers cancel a request if a mistake has been made?

3. How should the system respond if an invalid card is input?

4. What happens if customers try to put their card in before selecting a

destination (as they would in ATM machines)?

5. Must the user press the start button again if they wish to buy another ticket

to a different destination?

6. Should the system only sell tickets between the station where the machine is

situated and direct connections or should it include all possible destinations?

Add 3 more answer.

1. Can a customer change their destination after bought the ticket?
2. Is credit card is the only method to make a payment?
3. What type of input device (touchscreen vs keyboard) system support?

Q2. Write a set of non-functional requirements for the ticket-issuing system,

setting out its expected reliability and response time.

Answer:

Possible non-functional requirements for the ticket issuing system include:

1. Between 0600 and 2300 in any one day, the total system down time should

not exceed 5 minutes.

2. Between 0600 and 2300 in any one day, the recovery time after a system

failure should not exceed 2 minutes.

3. Between 2300 and 0600 in any one day, the total system down time should

not exceed 20 minutes.

4. After the customer presses a button on the machine, the display should be

updated within 0.5 seconds.

5. The ticket issuing time after credit card validation has been received should

not exceed 10 seconds.

6. When validating credit cards, the display should provide a status message

for customers indicating that activity is taking place.

7. The maximum acceptable failure rate for ticket issue requests is 1: 10000.

Add 3 more answer.

1. After the customer picked the location inside the system, it should take around 2 seconds to process.
2. It takes 2-5 seconds to print out the receipt.
3. After the customer inserted the money and has the change, the system should withdraw the change not exceed 5 seconds.

GROUP 1:

• ARIF ASNAWI BIN MOHD PAUZI (01DIS17F1047)
• MUHAMMAD FARID BIN MOHD ARIFFIN (01DIS17F1041)
• MUHAMMAD AKMAL BIN AHMAD FADZIL (01DIS17F1040)
• ABDUL RAHMAN BIN MESRUN (01DIS17F1061)
• MUHAMMAD HASNUDDIN BIN SALAHUDDIN (01DIS17F1062)
• MUHAMMAD AMIRUDDIN BIN ABDUL KADIR (01DIS17F1034)
• MUHAMMAD HAFIZ BIN ZUHARI (01DIS17F1037)
• AHMAD THAQIF ILMAM BIN ABDUL AZIZ (01DIS17F1035)
• NURUL IZZAH BINTI KAMAL FAISAL (01DIS17F1049)
• MIMI AMIRAH BINTI CHE ABDUL (01DIS17F1045)
• NUR AFIQAH BIN MOHAMAD RAMLEE (01DIS171057)
• KU NURAL' IZZATI BINTI KU KAMARUDZAMAN (01DIS17F1064)
• NURUL ELISYAH BINTI MUHAMMAD ARSHAD (01DIS17F1033)
• YASHELA A/P CHANDRANSANGRAN (01DIS17F1101)

Architectural Design and Models of Software Architecture (Group 4)

GROUP 4

• Nazaratul Kasrina binti Kamarulzaman (01DDT17F1011)

• Nurul Adlina binti Muhamad Zainal (01DDT7F1019)

• Anis Wahida binti Razik (01DDT17F1020)

• Siti Nur Mariah binti Abdullah (01DDT17F1030)

• Muhamad Aidil Irfan bin Ahmad Azali (01DDT17F1028)

• Mohammad Aizat Nazmi bin Mohd Satar (01DDT17F1034)

• Azrul Faiz bin Abd Aziz (01DDT17F1029)

• Mohammad Raihan bin Mohd Johari (01DDT17F1031)

Architectural Design and Models of Software Architecture (Group 1)

DFP5043 – Software Requirement and Design

Tutorial Lab4

Instruction:

Discuss and contribute together to answer  

the questions below and post the answer to the class's blog.

Don't forget to write your name in the blog.

Define and draw example of architectural design and models of software architecture below:

i.                    Architectural Design

ii.                  Logical View

iii.                Process View

iv.                 Development View

v.                   Physical View

vi.                 Scenario

• Architectural Design

An architectural model is a rich and rigorous diagram, created using available standards, in which the primary concern is to illustrate a specific set of tradeoffs inherent in the structure and design of a system or ecosystem. Software architects use architectural models to communicate with others and seek peer feedback. An architectural model is an expression of a viewpoint in software architecture.

• Logical View

The logical view is concerned with the functionality that the system provides to end-users. UML diagrams used to represent the logical view include, class diagrams, and state diagrams or which shows the key abstractions in the system as objects or object classes.

• Process View

The process view deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the runtime behavior of the system.

The process view addresses concurrency, distribution, integrators, performance, and scalability, etc. UML diagrams to represent process view include the activity diagram.
Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency.
In the Unified Modelling Language, activity diagrams are intended to model both computational and organizational processes (i.e., workflows), as well as the data flows intersecting with the related activities. Although activity diagrams primarily show the overall flow of control, they can also include elements showing the flow of data between activities through one or more data stores

• Development View

The Development Viewpoint is a considerable amount of planning and design of the development environment is often required to support the design and build of software for complex systems. It is the role of the Development view to address these aspects of the system development process.

Definition	Describes the architecture that supports the software development process.
Concerns	module organization common processing standardization of design standardization of testing instrumentation codeline organization
Models	module structure models common design models codeline models
Pitfalls	too much detail overburdening the AD uneven focus lack of developer focus lack of precision problems with the specified environment
Stakeholders	Production engineers, software developers and testers.
Applicability	All systems with significant software development involved in their creation.

• Physical View

The physical view depicts the system from a system engineer's point of view. It is concerned with the topology of software components on the physical layer as well as the physical connections between these components. This view is also known as the deployment view. UML diagrams used to represent the physical view include the deployment diagram. The following diagram is the UML deployment diagram:

• Scenario

The description of an architecture is illustrated using a small set of use cases, or scenarios, which become a fifth view. The scenarios describe sequences of interactions between objects and between processes. They are used to identify architectural elements and to illustrate and validate the architecture design. They also serve as a starting point for tests of an architecture prototype. This view is also known as the use case view. The following diagram is the use case view.

Overall:

GROUP 1:

• ARIF ASNAWI BIN MOHD PAUZI (01DIS17F1047)
• MUHAMMAD FARID BIN MOHD ARIFFIN (01DIS17F1041)
• MUHAMMAD AKMAL BIN AHMAD FADZIL (01DIS17F1040)
• ABDUL RAHMAN BIN MESRUN (01DIS17F1061)
• MUHAMMAD HASNUDDIN BIN SALAHUDDIN (01DIS17F1062)
• MUHAMMAD AMIRUDDIN BIN ABDUL KADIR (01DIS17F1034)
• MUHAMMAD HAFIZ BIN ZUHARI (01DIS17F1037)
• AHMAD THAQIF ILMAM BIN ABDUL AZIZ (01DIS17F1035)
• NURUL IZZAH BINTI KAMAL FAISAL (01DIS17F1049)
• MIMI AMIRAH BINTI CHE ABDUL (01DIS17F1045)
• NUR AFIQAH BIN MOHAMAD RAMLEE (01DIS171057)
• KU NURAL' IZZATI BINTI KU KAMARUDZAMAN (01DIS17F1064)
• NURUL ELISYAH BINTI MUHAMMAD ARSHAD (01DIS17F1033)
• YASHELA A/P CHANDRANSANGRAN (01DIS17F1101)