Greetings, All.

My name is Marc and currently a student of LBCC. I'm currently taking System Analysis and Design.

I'll be as straightforward as possible, I need to interview an IT Professional who performs requirements modeling activities in system development projects. This isn't much of an interview since I'm just asking any random professional to answer these questions. As I don't really know any at the moment. Two in the family that are ITT Tech graduates, but still doesn't have the experience working in a professional environment.

*I do hope this is quite alright for me to post. If not, I apologize and simply delete this post.*

There are really only three main questions in this 'interview.' The rest are information about the employee.

Here they are:

Name:
Job Title:
Company and Location:
Job Responsibilities:
Education:
Years of Experience:

Please mention some of your techniques and skills that you employ in your job:

What are the challenges that you are facing or have faced during the stage of the system analysis phase?

Please list at least three tips about conducting a successful requirements analysis:

Dani AI

Generated

This thread began when asked for a short interview with an IT professional for a systems-analysis assignment; the OP later reported success and marked the topic solved. For future students who land here looking for practical guidance, the following concise, evergreen pointers summarize what to look for and how to get useful answers from a practitioner about requirements modeling.

When interviewing someone who models requirements, focus on both technique and outcome. Ask how stakeholders are identified and prioritized, which elicitation methods are used in practice (interviews, workshops, observation, prototypes), and how findings are translated into concrete artifacts (user stories or use-case narratives, process or data-flow sketches, wireframes, acceptance criteria). Also probe facilitation and negotiation skills, how ambiguities are resolved, and how requirements are traced to design and tests. Request redacted or anonymized examples of artifacts where possible so answers aren’t purely theoretical.

Typical problems practitioners report are vague stakeholder goals, conflicting priorities, scope creep, missing acceptance criteria, and late technical constraints. Common mitigations include making assumptions explicit, capturing at least one concrete scenario per requirement, iterating with quick prototypes, and establishing a single source of truth plus a lightweight change-control process.

  • Start with a stakeholder map and the top 1–2 real scenarios to ground discussion; vague goals become testable when tied to a scenario.
  • Validate quickly: sketch a wireframe or walk through a mock transaction during the interview to reveal hidden rules.
  • Require acceptance criteria for each key requirement (done/undone) and keep traceability to design/tests.
  • Prioritize and timebox: identify the minimum viable scope for the next delivery and note deferred items.
  • Ask for lessons learned and one redacted artifact or a short, concrete example; practical failures teach more than idealized descriptions.

Practitioners who can cite concrete examples, acceptance criteria, and trade-offs are far more valuable for a school interview than those who speak only in concepts.

Recommended Answers

All 2 Replies

Master Rattley? Hm

Well, thank you for trying, anyway. This homework is done and I was able to find an IT Professional.

I have marked this as solved then... Glad you found what you wanted.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.